Ideal LabVIEW development PC

[geva]

Hi,

although I have a reasonably fast Laptop (Dell Latitude E5570, I7 8G, SSD), I am losing a lot of time working on a certain big (OO based) project. Opening and closing VI’s or typedefs is taking seconds. Even VI’s that have no override methods. I wonder if buying a faster PC will help. Therefore, my question is, what hardware will make the LabVIEW development environment faster and how much?

Faster processor, more cores, better GPU (unlikely to help I guess) , faster RAM, SSD?

Thanks, Geert

[wiebe@CARYA]

Geert,

Same situation over here (large OO projects). CPU isn't maxed out, nor is memory. As all classes are loaded when the project loads, I'm pretty sure disk speed is the bottleneck. So a SSD would definitely help.

I would be interested in performance tricks regarding OO structure. Are there certain OO things you can do or shouldn't do to that will increase loading? I guess everything has to be loaded at least once, and is probably loaded exactly once. So structure probably doesn't matter at all. Can anyone confirm that?

[Hooovahh]

SSD is probably a big factor.  Beyond that you might want to look into removing the mutation history on the class. 

http://digital.ni.com/public.nsf/allkb/F0FC362A73C794BA86257C6700692B0B

For many large projects using lots of classes, this old mutation history might not be useful.  It can be but I haven't needed it yet.

[geva]

Clear mutation history.vi is a VI that is already in my project. I run this often. Without this, opening a VI sometimes takes 10 seconds. Besides this we create our own class hierarchy for faster loading and we have more than one project file to fasten development work.

Loading is not that a problem, I can stretch my legs while doing that. Having to wait 1.5 seconds every time I open or close a VI or type def is so irritating....

[wiebe@CARYA]

---

Hooovahh wrote:

http://digital.ni.com/public.nsf/allkb/F0FC362A73C794BA86257C6700692B0B

For many large projects using lots of classes, this old mutation history might not be useful.  It can be but I haven't needed it yet.

---

That sounds very promising. I was sort of "expecting" the project getting slower, since the project is getting bigger. Can't wait to commit my current changes and try it out!

What is the worse that can happen? It will of course trigger SCC on all classes. Are there other downsides on doing this every now and then? Other then (un)flattening getting broke.

[Hooovahh]

---

wiebe@CARYA wrote:

---

What is the worse that can happen? It will of course trigger SCC on all classes. Are there other downsides on doing this every now and then? Other then (un)flattening getting broke.

---

I think that is it.  Also there is an idea to make this feature easier to access.

[wiebe@CARYA]

I attached a little tool that clears the mutation history for all classes in the current project.

I have 242 classes. Removing the history reduced my project with ~1.8 MB (1800000 bytes).

After a LV reload, load time shrunk from 1:59 s to 1:00 s.

After closing and reloading, load time shrunk from 1:15 s to 0:58 s.

Might be measurement noise though, but feels good.