LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Editing in 2011 much, much slower than 8.6

Currently working on a large project with over 1000 VIs with a few of them being very large VIs.   This project also uses the The StateChart Module.

 

When editing one of the large VIs in 8.6, adding or removing anything from the block diagram means having to wait a few seconds after doing so.  This is annoying.  But liveable. 

 

When I migrated the code to 2011, a few seconds became a few minutes.  I tried ctrl+shift when running the top level VI.  I even ran a mass compile on all of the VIs.  No help.  Even saving a VI in 2011 was taking forever.  There would be a several minute pause before any of info dialogs would even pop up. 

 

I can't really afford to lose more than the 8 hours I already have, so I've begrudgingly reverted back to 8.6 for now.  But I'm curious if anyone has any insight as to why I would be taking such a performance hit during editing.  Any thoughts on how to fix this problem would be welcome as well.

---------------------
Patrick Allen: FunctionalityUnlimited.ca
0 Kudos
Message 1 of 4
(2,469 Views)

I am curious: Did you ever try it in LabVIEW 2010? That's when the new compiler was introduced, taking longer to compile (see e.g. slide 13 here), but creating code that is more optimized.

 

What kind of computer hardware do you have. LabVIEW 2011 has SSE2 support, so if you have an old CPU that does not support SSE2 things are not optimal either. 

0 Kudos
Message 2 of 4
(2,449 Views)

I have experienced the same problem and have been working with NI to understand why.  I have not done enough testing to know 100% the reason, but right now I think it’s the hard drive.  Today I upgraded to a solid state drive and my editing is now faster than it ever has,  and I have been running 2010sp1.  My guess is when editing large vi’s, the
edits are stored on the hard drive.

 

I will be monitoring the performance difference and reporting back what I find.  My belief right now is SSD is the only way to go!

0 Kudos
Message 3 of 4
(2,411 Views)

Yes, I did try the code in LV 2010.  Although I didn't do very much, if any editing of the code. It's possilbe the same thing is going on. 

 

So far I've experienced very slow editing on two different PCs.  One laptop that's a Pentium dual core with 4G and one desktop that's an AMD quad core with 8G of ram.  Both in the 2.2Ghz cpu range.

 

This code makes heavy use of an add on toolkit that uses a lot of internal scripting. 

 

I'll have to test it again to confirm, but things did seem to be working much better when I did a quick test on an i7 laptop. 

---------------------
Patrick Allen: FunctionalityUnlimited.ca
0 Kudos
Message 4 of 4
(2,384 Views)