altenbach,
Thanks for the quick reply--very helpful suggestions and questions. It is interesting that you don't notice slow performance for editing the front panel. I moved Master.vi and all of its subvi's onto another machine running labview 2010 SP1 (32 bit) and Windows XP. The performance for editing the front panel was better but still sluggish. I then reloaded Master.vi without any of its subvi's and the performance is very good (on the XP machine.)
Back on the original machine running Windows 7, one of the most reproducible time delays when editing the front panel is generated by changing the Display format of a control. When I do this in Master.vi (with all subvi's loaded), I get about a 10 to 15 second waiting period after I hit OK. Without closing Master.vi, I can create a numeric control and change its display format in about 1 second. If I reload Master.vi without any subvi's I see some improvement when I change Display Format, only ~5 seconds of spinning circle.
To answer your questions.:
I am running Labview 2010 Version 10.0.1 (64-bit). The OS is running in 64bit mode.
I specficially was promised nothing about SP1, but I knew that one issue addressed in SP1 was faster save times. Installing it did decrease the time to save,but 1 to 3 minutes to save still seems unreasonable. Saving was faster (~<30 seconds) in 2009. Editing the front panel had already slowed down in labview 2009, and we hoped it would get faster in 2010. It is hard to guage the difference in editing speed versus labview version because the vi has become more complex over time. To be clear, the code runs great except for this slow-down issue and the occassional bomb.
The top-level vi became corrupted once in Labview 2009 over the course of ~1year. The same vi has been corrupted 2x in ~1.5 months in Labview 2010 SP1. I can't compare to 2010 because saving was taking so long that we immediately installed the upgrade. Previous to Labview 2009, I have never had a copy of a vi saved to disk become corruptted such that it won't open.
I agree, we tend to be sloppy about coercion outside of loops. We do our best to pay attention to coercion inside of loops. Is there a concrete way to calculate the coercion cost in memory and cpu ticks?
Is there a reference for having overlapping controls causing problems--sort of a do's and don'ts of how to reduce overhead associated with updating the front panel. A quick search around the labview site says don't do overlap controls. I remember that in Labview 5 or 6ish (in Mac OS9 ), I found that tabs caused terrible slow downs for editing or execution (can't remember which) and I thought this kind of overlap problem was fixed.
Again, thanks for the feedback--it is much appreciated.
James
