LabVIEW 2009 slow performance

[EWTech]

I actually did that when I realized what was happening. The difference in overall size is not that much. An increase of say 20 - 30% or so is not something that would cause this kind of a stall. Once would expect the slowdown to be in the same range in terms of code increase even though it does not always work that way. For the huge difference in performanace I've seen I would expect the size to double or close to it.

[Joe_H]

Have you tried mass compiling your VI's in 2009. A lot of the slowdowns people run in to when upgrading code to a new version is the fact that they just open the VI in the current version and run it.

Try mass compiling and see if that helps. Make sure you mass complie all of your VI's not just the top level. It is best to compile the whole folder that you use.

Message Edited by Joe_H on 09-17-2009 03:24 PM

[Ben]

Those are all shared variable reads?

Could a setting for the library have been wacked out?

There are all wired in series so is ther any one that is taking longer?

Just trying to help,

Ben

[EWTech]

I tried mass compiling this as suggested and paid attention to Task Manager after both ran. Mass compiling this had no effect but I did learn something: The figures I gave for the executables are correct but LabVIEW running underneath everything is almost twice as big. I get 84MB for LabVIEW running the same project under 8.6.1 and 155MB for the LabVIEW running the same project under 2009/9.0. There is bloat there but that is labview.exe! Is anyone else seing this or do I have an extremely poorly configured installation?

[EWTech]

The shared variable is a shared shared variable... Sorry, but I really couldn't help it...There are two shared variables configured as a long string that propogates a series of values as a series of lines in the form [<Channel_Name_String>; <Floating_Point_String_value><CRLF>]. The semicolon is the string separator between the channel name and the floating point string. It's a really long string and the StringToVars DLL is the means used as a linear string lookup. It's really fast native. The whole thing is being hampered by something in LabVIEW itself since it takes the same 90 seconds to open the vi from the project file.

God save us from zero-point-releases.

[TimTower]

I am also having problems with slow performance of LV2009SP1, during development (exes run fine). I have a relatively large VI called ACSYSoft.vi which I have just ported over from LV711. It runs and compiles OK under LV9SP1. But development is very slow, and is impacting my productivity.

The VI’s memory stats are as follow:
FP: 254 K
BD: 5330 K
Code: 793 K
Data: 408 K

I have 3 identical PCs, each with Tyan S2865 Mobo, Athlon 4200X2 dual core, 2x 2GHz, 2 GB Ram, WXP SP3 with latest updates. One has LV711 and the other two have LV2009SP1. I have mass compiled both the project Vis and everything in the \Program Files\ NI folder (the latter taking many hours!). However, mass compiling made no difference to the results below.

The PCs have different Antivirus programs (Avast5.0 and Norton 2009). I disabled both of these AVs, as well as the Windows firewalls – no difference.

Times are in seconds. (Data from three A42 PCs):

                                                              LV9       LV711
B1.Opening LV    (first time)                                30-40       4      
B2.Loading ACSYSoft.lvproj (first time)  (LV closed)         45-50
B3.Loading ACSYSoft.lvproj (subsequent times) (LV closed)    17-20
B4.Adding a Boolean (no code) & saving                       30-32        2
B5.Adding a while loop, time delay, stop btn & saving        50-60       2-3                   
The slower load times are tedious but one doesn’t load that often. One thing interesting – the library \vi.lib\Analysis\NI_AALPro.lvlib can take 15-20 sec to load. Not sure why.

The most serious problem is the time taken to save a change. With the A42 PCs, LV9 takes 15 times longer. If a recompile is required (e.g. with a While loop addition), it seems to first save (30 sec) then recompile (another 20-30 sec) – the total time is very long – nearly a minute. Note that after this is done once, the recompile is fairly fast (a few seconds, vs. 20-30), but the saving time is unchanged, so the overall time is still around 30-35 sec.

Several readers have mentioned possible memory limitations. This does not appear to be the case with my PCs, each of which has 2 GB total. I checked the Available Memory using SysInternals Process Explorer:

                                                   Avail Mem(MB) – A42
A. After Startup, with minimal Apps running                   1417
A1 - As A, but with LV9SP1 loaded                             1318
A2 - As A, but with ACSYSoft.lvproj loaded                    1295
A3 - As A, but with ACSYSoft.lvproj + ACSYSoft.vi opened      1269
A4 - As A3, after adding an LED to ACS and saving (30 sec)    1193
A5 – As A4, but running the ACSYSoft.vi.                      1170

The above tests were done on identical desktop platforms (two with LV9SP1, a third with LVV711). I also tried my laptop, a Dell Precision M90, WXP SP3, with 2 GB ram and a dual core 1.8 GHz Intel CPU. Its Process Explorer memory stats were similar to the above. However, it was about twice as fast as the A42s: Test B4(Adding a Boolean & saving)  took 13-15 sec (vs. 30-32) and B5(Adding a while loop, time delay, stop btn & saving) took 26 sec (vs. 50-60). I don’t know why this is faster than the A42s. Nevertheless, it is still 7- 8 x slower than with LV711.

I need to figure out what is going on here. In the meantime, I can try working on my laptop, although it is still slow, not as convenient, and has limited screen space.

Thanks in advance for your help.

Tim Tower

[TimTower]

This is a follow up to my post of 3-30-2010, re the slow performance of LV2009 on my Athlon A4200X2 PCs.

On one of these PCs (A42tmt2), I have a triple boot, with W7pro, WXPpro and W2000pro, each in its own partition. For comments on installing W7 in a multi-boot environment, see Note 1 at end.

I ran the above tests (see 3/30/2010) on A42tmt2 using LV2009 under W7, and the times were unchanged. Conclusion: the slow performance of LV2009 is unrelated to the OS (WXPpro or W7pro).

I then installed LV861 under WXP on A42tmt2. (I left LV2009 installed). I repeated the tests. LV861 was almost as fast as LV711 – i.e. 4-5 sec to save and compile a change that takes 30-60 sec under LV2009 and 2-3 sec under LV711. Conclusion: the slow performance of LV2009 is most likely related to a conflict (on my PC ) which does not occur with LV861 or 711, or it is related to a problem with LV2009. I find the latter hard to believe, as I am sure all those smart & dedicated NI developers would have seen this. So, I wonder what the problem is with my PCs?  

A42tmt2 has a completely new WXP install, done on a formatted partition less than a month ago. It has WXPpro SP3 and all the latest Windows updates. It has few extra Apps, although the ones I am using may be the culprits – hard to say. I am including a list of all the Apps installed – see “A42tmt2_MyUninstaller_21010405.xls”, attached.

I have since ported my App back to LV861 so that I can get my work done. It is working fine. However, I would like to be able to use LV2009. Any ideas out there?

Note1: It is easy to install W7 on a PC which has WXPpro installed (and have a dual boot), but be advised that W7 will always take over the C: partition. I first tried installing W7 in a new G: partition (with my User Files on C:, W2K on 😧 and WXP on F:).  W7installed OK, but after rebooting, it hid my original C: partition and renamed the G:partition "C:". Hence, if you wish to be able to see your original C: partition, you must install W7 in the C: partition. If this is where your WXP is installed, you will have an issue. Either reinstall WXP in another partition (I use F :), or overwrite the original XP install with W7, or put up with having your XP partition hidden when you boot to W7. WXP doesn’t care if W7 is installed on another partition, and WXP doesn’t have to be on the C: partition. W2K doesnt care either.

[EWTech]

I've sort of given up on this for the moment. In my case there is only so much time or resources to throw at this. I have requested Win. 7 for test purposes to see how it affects my applications. I doubt it will matter much. As to the question of performance for the current version my earlier comment about zero point releases still stands...

I'm not looking for a conspiracy. I just want my code to work correctly with the current development environment. It doesn't right at this moment. Maybe next time. If it does not without complete reconstruction I will have to consider building the whole thing using Visual Studio. It may be harder but it tends to be more stable as a development platform. I have access to Measurement Studio and I've had a lot of things work very well with it. LabVIEW as a moving development target is a loosing proposition from my perspective. I would rather use the time to add fuction and and additional sensors to my projects rather than to rework them from scratch so that they continue to function.

Bob

[EWTech]

This is a duplicate from an entry of mine elsewhere on the forum about the same issue but...

I want to test on the newer PC but the issue seems to be an effect of how the NI Variable Engine responds to some registry settings.

There is a page on the digital.ni.com/public tree titled “Why does tagsrv.exe Memory Usage Grow Until it Crashes?” I have implemented option 1 on the test system and it cut the startup time roughly in half. I have set the setting value to 8,000,000. The variable engine architecture seems to have changed drastically and this seems to be what is stalling the application from loading as quickly as it should. Once the panel loads on the screen there is another half-minute delay waiting for shared variables to percolate through and start to display live data rather than default (usually zeroed) data.

The description says that if this is causing the error and the variable engine is swamped there should be error -180121600 or error -180121601 describing a message queue overflow. I get no error messages at all from variable read widget at all and the error output is wired as expected.

During the build I made sure that debugging is off and memory usage seems to be reasonable for a newer LabVIEW version – it never decreases but usually increases somewhat modestly once the application has debugging off and the correct settings in the VI properties panel for application efficiency.

The machine in question is running Windows XP 32 bit, has a Pentium 4 CPU and 4 GB of RAM (the main board is maxed out). Trying the executable on a PC with a Core 2 dual core CPU and 2 GB of RAM shows similar results though I have not tested the registry change on that machine.

[EWTech]

I was messing around with the Variable Engine options and found that setting the sleep time to something less than the default of 60 seconds speeds things up quite a bit. I have to have the value greater than 30 seconds or the values displayed are set to zero briefly as if the variable engine is suddenly purged and takes a moment to reload from the variable source over the network. Does this make any sense?

This was added to this thread at the suggestion of one who's busy drinking the coolaide...