Serious performance issue with LV 7.1 Development Environment

[Rob_Calhoun]

I'm posting this issue to the forums prior to submitting a bug report to ensure that the problems I'm having are reproducible. To reproduce this bug, you're going to have to be an advanced user with a large project (hundreds to thousands of VIs) as the performance problem is related to the number of VIs loaded.

The issue is the increasingly poor performance of the LabVIEW 7.1 Development Environment as the number of VIs in memory increases. The actions affected include switching between front panel and diagram, saving a VI, copy and paste, clicking a menu, and the mysterious time spent (compiling? editing the runtime menu? changing the toolbar state?) between pressing the run button and when the code actually starts executing. Scrolling and, interestingly, copying via a control-drag are not affected. Running time of entirely on-diagram code does not seem to be affected.

These problems are quite severe and significantly decrease my productivity as a programmer. Since they are development environment UI issues, it's been difficult for me to find a good example VI; the best I can do is the attached "LV Speed Test.vi". It doesn't test the issues that affect me most, but it seems to suffer from the same problem.

This simple VI just shows and hides the menu bar 100 times in a tight for loop. When it is the only VI loaded, it executes in about 350 msec on my machine. (2.4 GHz P-IV/640 MB RAM/Win2k). However, when I load a single project-encompassing VI (let's call it the "giant") that references a total of about 900 user and VI-lib subVIs, the test routine takes almost a minute and half to run...about 240 times slower! I've tried this on my laptop with similar results.

The problem appears to be related to the *number* of VIs loaded and not the memory utilization. For example, if I close the "giant", and create a new VI ("memhog") that does nothing but initialize a length 20,000,000 array of doubles and stores it in an uninitialized shift register, LabView's overall memory usage (as shown in the task manager) jumps enormously, but LV Speed Test executes in about 450 msec...only slightly slower than with a fresh copy of Labview.

The problem seems to be related to excessive context switching. The Windows task manager shows over a thirteen hundred page faults occur when "LV Speed Test" is run with the "giant" in the background, versus zero or none when run by itself or when "memhog" has used up 160+MB of space.

The problem only seems to affect the frontmost window. (Unfortunately, that's where we LV programmers spend all of our time!) If you start "LV Speed Test" and then put "giant" in the foreground "LV Speed Test" runs much faster. In fact, if you use the VI server to put the "giant" VI in the foreground programmatically at the start of "LV Speed Test", execution time drops back to 450 msec, and there are no page faults!

These results show the issue is not related to video drivers or the Windows virtual memory system. My suspicion is that there is a faulty routine in LV 7.1 that is traversing the entire VI hierarchy every time certain events are thrown in the foreground window. It could be due to a problem with the Windows event tracking system, but this seems less likely.

I have been programming LV for about 7 years and switched from LV 6.1 to 7.1 about four months ago. I know NI engineers have put thousands of hours developing and testing LV 7.1, but honestly I find myself wishing I had never upgraded from using LV 6.1. (To whomever thought "hide trailing zeros" should be the default for floating point controls...what were you thinking?!)

I know each new version of LabView causes old-timers like me to grouse that things were better back in the days when we etched our block diagrams on stone tablets, etc., and honestly I'm not going to go back. I am committed to LabView 7.1. I just wish it were not so slow on my big projects!

[Wiebe@CARYA]

Hi,

I can confirm this behavior. Setting the execution system to "user
interface" helps a bit, but there is still a big difference.

I get a feeling it has something to do with window messages, perhaps
WM_PAINT or something, that is handled differently if a VI is not
frontmost... But what do I know...

Don't know if it should be called a bug, but it sure is something that could
be optimized.

Regards,

Wiebe.



"Rob Calhoun" wrote in message
news:506500000008000000AEF20000-1079395200000@exchange.ni.com...
> I'm posting this issue to the forums prior to submitting a bug report
> to ensure that the problems I'm having are reproducible. To reproduce
> this bug, you're going to have to be an advanced user with a large
> project (hundreds to thousands of VIs) as the performance problem is
> related to the number of VIs loaded.
>
> The issue is the increasingly poor performance of the LabVIEW 7.1
> Development Environment as the number of VIs in memory increases. The
> actions affected include switching between front panel and diagram,
> saving a VI, copy and paste, clicking a menu, and the mysterious time
> spent (compiling? editing the runtime menu? changing the toolbar
> state?) between pressing the run button and when the code actually
> starts executing. Scrolling and, interestingly, copying via a
> control-drag are not affected. Running time of entirely on-diagram
> code does not seem to be affected.
>
> These problems are quite severe and significantly decrease my
> productivity as a programmer. Since they are development environment
> UI issues, it's been difficult for me to find a good example VI; the
> best I can do is the attached "LV Speed Test.vi". It doesn't test the
> issues that affect me most, but it seems to suffer from the same
> problem.
>
> This simple VI just shows and hides the menu bar 100 times in a tight
> for loop. When it is the only VI loaded, it executes in about 350 msec
> on my machine. (2.4 GHz P-IV/640 MB RAM/Win2k). However, when I load a
> single project-encompassing VI (let's call it the "giant") that
> references a total of about 900 user and VI-lib subVIs, the test
> routine takes almost a minute and half to run...about 240 times
> slower! I've tried this on my laptop with similar results.
>
> The problem appears to be related to the *number* of VIs loaded and
> not the memory utilization. For example, if I close the "giant", and
> create a new VI ("memhog") that does nothing but initialize a length
> 20,000,000 array of doubles and stores it in an uninitialized shift
> register, LabView's overall memory usage (as shown in the task
> manager) jumps enormously, but LV Speed Test executes in about 450
> msec...only slightly slower than with a fresh copy of Labview.
>
> The problem seems to be related to excessive context switching. The
> Windows task manager shows over a thirteen hundred page faults occur
> when "LV Speed Test" is run with the "giant" in the background, versus
> zero or none when run by itself or when "memhog" has used up 160+MB of
> space.
>
> The problem only seems to affect the frontmost window. (Unfortunately,
> that's where we LV programmers spend all of our time!) If you start
> "LV Speed Test" and then put "giant" in the foreground "LV Speed Test"
> runs much faster. In fact, if you use the VI server to put the "giant"
> VI in the foreground programmatically at the start of "LV Speed Test",
> execution time drops back to 450 msec, and there are no page faults!
>
> These results show the issue is not related to video drivers or the
> Windows virtual memory system. My suspicion is that there is a faulty
> routine in LV 7.1 that is traversing the entire VI hierarchy every
> time certain events are thrown in the foreground window. It could be
> due to a problem with the Windows event tracking system, but this
> seems less likely.
>
> I have been programming LV for about 7 years and switched from LV 6.1
> to 7.1 about four months ago. I know NI engineers have put thousands
> of hours developing and testing LV 7.1, but honestly I find myself
> wishing I had never upgraded from using LV 6.1. (To whomever thought
> "hide trailing zeros" should be the default for floating point
> controls...what were you thinking?!)
>
> I know each new version of LabView causes old-timers like me to grouse
> that things were better back in the days when we etched our block
> diagrams on stone tablets, etc., and honestly I'm not going to go
> back. I am committed to LabView 7.1. I just wish it were not so slow
> on my big projects!

[johnsold]

I don't see anything like this on the Mac. I opened a bunch of examples since I did not have a large project handy. Using the profiler window, I estimated that about 400 VIs were in memory (about 40 front panels open). The Speed Test VI reported about 4670 ms on a 450 MHz G4, LV7.1, OS X, 10.3.5, 384 MB. The Profiler reported VI time of about 2200 ms for the same runs. I did not observe any change in responsiveness to opening diagrams, etc. With only Speed Test in memory it ran in about 2800 ms (Profiler 420 ms). When I ran one of the examples which modified the menu and then ran Speed Test simultaneously, it ran quite a bit slower, but that seems reasonable with multiple menu bar changes.

Lynn

[Ben]

I was able to duplicate this in LV 7.1 running under Windows.

I have also noticed some slow "save" performance in LV 7.0 on two seperate machines.

Ben

[Ben]

I had forgotten about the priority boost setting!

http://zone.ni.com/devzone/conceptd.nsf/webmain/28A6979ECA9A0CAF862569050053D92D?opendocument

This seems to have made a difference.

Ben

[Rob_Calhoun]

Thanks for trying to replicate this bug!

I changed Windows' performance option from "Applications" to "Background Services". This had little effect on the overall runtime (88 seconds to 87 seconds). It did add some additional artifacts to the toolbar show/hide.

-Rob

[m3nth]

I ran this with typical performance of 400-600ms with nothing loaded, and >2000ms with a large app of about 400+ VI's loaded.

[KileenC]

Hi Rob,

I have submitted this issue as a potential bug for R&D to investigate.

In the meantime, you can take a look at the NIDZ Application Note LabVIEW Performance and Memory Management for additional tips.

Thanks again!
Kileen C.
NI

[Rob_Calhoun]

Kileen,

Thanks for submitting this issue to engineering. Please don't hesitate to contact me if more details are needed.

-Rob Calhoun

[Ben]

See this thread for related info

http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=5065000000080000009DF10000&USEARCHCONTEXT_CATEGORY_0=_49_%24_6_&USEARCHCONTEXT_CATEGORY_S=0&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0

Ben