Large scale applications using LVOOP

[LAVA 1.0 Content]

The discussion under topic AddItem method doesn't work if class belongs were going too much off topic so I decided to start a new topic here. I first refer the previous discussion here and the go on the discussion in my next post.

Opening a project simply opens a file listing. It does not load all the VIs into memory (the project is designed to be a manager for very large projects where you might not want all the VIs in memory simultaneously). The same is true for a library -- .lvlib files do not load all their VIs into memory.

This distinction between class and library explains why my library of hundreds of subVIs worked very well as a conventional subVI library. Now I have encapsulated the same behaviour into a class hierarchy which also includes several hundreds VIs and LabVIEW seems to freeze when I open the project containing the class structure. If I understand you correctly opening the project should not open the classes within the project, but... it still takes a very long time to load the project.

Actually, I think Aristos was a little ambiguous. loading projects do load some "referenced files". They will load their libraries. For regular project libraries, this means it will not load any of their VIs, but for classes and XControls, it will load VIs/CTLs/sublibraries/parent classes/etc. that belong to them. That is why probably why loading your project takes a such a long time. Those VIs are all being brought into memory.

Unfortunately, this behavior actually is expected, though we realize it is not ideal. Aristos can explain better than I why this is necessary.

I'm quite worried about the issue that arise from the previous discussion. It seems that there may be some serious problems related to large scale projects using LabVOOP. As far as I understood correctly, all of the class methods are loaded into memory when a project containing the class is loaded.

In modular software development, classes are often packed together into libraries and also LabVIEW encourages this behaviour. Libraries are then used as modules to include some needed functionality to the project. This is done by including the library to the project. One may need functionality present in several libraries. As a result developer may need to include quite many libraries to his project. Including all the module doesn't mean that all the methods are actually used in the project. It's quite often the case that only a few methods are actually used from each class library. Now it seems that LabVIEW loads all the methods of all the classes of all the libraries to memory when the project is opened. It also loads all the methods and subVIs referenced in these methods.

As a result, even quite simple projects may require loading several thousands of VIs to memory before the project explorer can even open. I see this as a extremely severe problem that will plenty of difficulties for most LAVA users in the future if the behaviour is not fixed.

Currently I have a project that doesn't open at all any more. Well it could open if I waited long enough, currently I have got tired of waiting after two hours of LabVIEW loading project components. This behaviour was a result of including a polymorphic VI containing several hundreds of reentrant VIs to several hundreds of dynamic methods. Each dynamic methods was used by static method. Several hundred of these static methods were then added to polymorphic VI. Well, this is a dead-end because it requires probably creating thousands of copies of the reentrant subVIs to memory even before the project containing the class can even open.

[LAVA 1.0 Content]

I give you some numeric background of the problems I have encountered. I have a project that contains two libraries. Each library contains six classes and about 500 methods. I have one top-level VI that uses about ten methods, the rest of the methods are not currently used. Theoretically about 20 methods are required at run-time to be able to run the main VI and call correct dynamically dispatchable methods.

Whe I open the project containing the main VI and the two libraries on my laptop (Pentium M 1.6 Ghz with 1GB memory running Windows XP SP 2) it takes five minutes to open the project. After having opened the project LabVIEW consumes a little over 100MB memory according to task manager. This means that if I would add a few more libraries to my project, I would reach the limits of the system.

If one considers a normal OOP project on mainstream programming languages, a common project may use several dozens of modules corresponding to LabVIEW libraries. Each module may contain up to several hundreds of classes and easily several thousand of VIs. From these modules developer perhaps really uses up to several hundred different classes and several thousand methods. To open such a project on LabVIEW 8.20 would require loading about 100 000 methods to memory. This would require system resources exceeding those available on personal workstations in next five years. I really think this is a huge problem. Something really needs to be done to fix the issue.

Edit: More statistics. I moved support for unnecessary data types and reduced the time to load my project to 2 minutes and 50 seconds. I however noticed another annoying thing. It takes 30 seconds after I press run button for my main VI to start actually running. According to profiler it actually runs for 0.01 seconds, so the rest of the time LabVIEW is doing some internal tasks... I verified that this is actually the case by placing some probes on the diagram to follow the execution. The first class constant was initialized after thirty seconds.

[Aristos Queue]

I however noticed another annoying thing. It takes 30 seconds after I press run button for my main VI to start actually running. According to profiler it actually runs for 0.01 seconds, so the rest of the time LabVIEW is doing some internal tasks... I verified that this is actually the case by placing some probes on the diagram to follow the execution. The first class constant was initialized after thirty seconds.

Known issue... the performance hit is due to excessive recompiling. Already being dealt with.

[LAVA 1.0 Content]

Known issue... the performance hit is due to excessive recompiling. Already being dealt with.

Ok. This is however smaller of the two performance issues I brought up. The issue related to loading all related classes and methods to memory is the most serious problem. More serious than anything I have complained this far.