Darren's Weekly Nugget 10/19/2009

[Ben]

Thank you Scott for that post. It has been a long time since I had to do a crash dump analysis (VMS circa 1994) but those thought are still present although seldom tickled, so it's nice to refresh those ideas out loud.

Again thank you,

Ben

[F._Schubert]

Very intersting stuff you are writing. I hope you keep on digging...

So one thing you should do for your tests is to run your tester vi's under highest priority. This should eliminated (at least reduce) the other processes from interfering.

And to throw in some very limited knownledge: on Win there is the MapViewOfFile (hope that's correct) in kernel32.dll. There you have a set of flags, where one is NO_CACHE. Here my knownledge ends...

One more issue is with the LV platform itself. It starts a lot of services, so maybe this might explain the difference between reboot and logoff. So it should be important to introduce a settling time before starting the tests (there was also something about loading options of the palettes ...). Also it might be intersting if Deallocate Memory after closing the reference in the tester has any effect on subsequent loads...

Felix

[sth]

@Felix,

I could run it at a higher priority but that is *only* a priority within LV.  Changing the vi priority will not change how the system responds to external tasks.  You cannot change the system priorities from within a VI or you end up with an insecure OS.

I could change the "nice" value for the OS process for LV giving it more CPU time.  But that will not change priority for disk blocks cached by the IO system.  Changing the caching algorithm for the disk cache is a very low level hack.  Even if I did that, what would it really tell me?  I mentioned the other number of processes so that one could get an idea of the amount of competition for the disk cache in memory.  The other thing is as I said, the results posted were for a slow single disk laptop but were much faster than my raid array on my desktop.

As for the settling time, I let the system settle a bit after the login to get all the login processes spawned.  As for the time after launching LV I did not see a big variation in that.

Good ideas.  But I still haven't gotten to the bottom of why this is such a big performance gain.  Now I will just have to try two test VIs with that 100 MB text box on the BD to see if it is merely file size.

[Ben]

---

sth wrote:

...

Good ideas.  But I still haven't gotten to the bottom of why this is such a big performance gain.  Now I will just have to try two test VIs with that 100 MB text box on the BD to see if it is merely file size.

---

Well that is a very good idea since LV should compile those away.

Ben

[Asad_Tirmizi]

Hello Darren.

Ive found your nugget very useful, I use LV 8.2. My prob is that i havent understood the procedure for making the block diagram disappear.

How do u create a "source distribution" build specification.

Where is the souce file settings ?

[Ray.R]

Hi Asad,

Which package of LabVIEW installation do you have?  Basic / Full / Professional /  Development Suite

You typically need the Professional or Dev Suite to compile applications, which are done within the project explorer.

You may have the application builder add-on which works with the Professional version (not sure about the basic package).

[Darren]

You must create a new LabVIEW project.  Once you have added your VI(s) to the project, right-click the "Build Specifications" item in the project and choose New > Source Distribution.  Source File Settings is one of the pages that appears in the resulting dialog box.   

-D 

[Jarrod_S.]

FYI: I added an additional caveat for removing block diagrams in a post here regarding LabVIEW classes and inheritance.