vekkuli

This thread got me to reorganize my workspace and project structure to most importantly improve load and build times and reuse workflow. It came to me as a surprise that LVLIB's although great in some ways force static links to everything in the library. I had previously seen this with classes but for some reason didn't expect the same from LVLIB's. Anyway, I ended up breaking apart a lot of reuse code and restructuring a large project. This seemed obviously a pretty daunting task at first and I was looking to utilize the "links" application by JackDunaway/Wirelabs. Unfortunately, I didn't manage to get it working fully so what I ended up doing was grabbing the hidden "App.Read Linker Info From File" invoke node from the code and searching the list for items where links jump to unintended libraries etc. The few hours of work were definitely worth it and I can recommend similar procedure to anyone starting to see the effects of unwanted coupling.

This is a standard thing to learn with SQLite, which is an “ACIDâ€-compliant database.  The “D†is for durable; by default SQLite is durable against power-failure of the computer, meaning once a transaction has executed, in can be relied on to remain, and not be corrupted, even if power is lost in a subsequent transaction.  Durability requires that SQLite verify proper writing to hard disk, and as hard disks spin at about 100Hz, this mean that the number of durable transactions is limited to an order of 20 per second.

 

You can disable the durability requirement, but a better strategy is to group multiple INSERTs into a single transaction by wrapping them in BEGIN…COMMIT SQL statements.  See on of the Examples provided with the package to see how this is done (you just need to execute “BEGIN†before your loops and “COMMIT†after**).  For simple INSERTs, one should get greater than 100,000 per second.

 

**also see SAVEPOINTs in the www.SQLite.com documentation.

Right you were. I was looking for the examples in the wrong place earlier. Grouping into a transactions definitely did the trick. Thank you very much for quick support.

I was very curious about this library and thought I'll give it a spin to see if I can use it in my application. In the first test, however, I already ran into a game stopper with the insert speed. Perhaps I'm doing something all wrong—you can take a look at the test code—but utilizing the "INSERT many rows Template code.vi", that to my knowledge should be an efficient method, I'm getting around 10-20 inserts per second. That's more than an order of magnitude less than what I was expecting or what I'd need.

Is this normal or should we try to find an issue here?

Other than that, the library seems very nice. Good job, and thank you for sharing it with us.

EDIT: "PRAGMA synchronous=OFF;" does speed it up to around 500 inserts per second which is already around half-way to what I need.

Just to add to this, in case someone else also finds this thread while googling about the problem, the "Grayed Out" seemingly applies an alpha mask that is of the same color as the natural background of the widget.

Has anyone discovered a way to reimplement the grayed out effect?

I made a thread on the NI forums about my problem as well: http://forums.ni.com/t5/LabVIEW/Build-Specifications-Programmatically-Adjusting-quot-Source-File/td-p/2857418

I was looking to automatize defining the build specifications as well but I never did scripting of this sort before, so I'm a little lost. Basically I wanted to take care of, well, this http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/compiler_optimizing_for_execution_speed/ (400+ VI's, Select each VI and clickety click click... NOPE). Anyway, I didn't get much further than being able to edit the tags I saw were already there. How would I, for instance, go through every source file/VI and define both of those properties (Uncheck "Use VI Property" and "Allow Debugging")?

Same here. I have LV2013 and Avast2014, can't even seem to find a way to restore the file, it's not in the "virus chest" at least.