Darren's Occasional Nugget 06/12/2023

[Kyle97330]

Maybe I should clarify the reasoning behind my questions then...

We have some projects that had EXE build times longer than are ideal.  Some were at the point where it was a random chance whether they'd finish the build before crashing.  Upon seeing this Nugget back in June, we did a manual pass trying to remove circular dependencies and it did seem to help.

Because it did seem to help, I made a little utility that does its best to trace dependencies between classes to identify circular relationships not only as existing, but specific VIs containing specific references that cause the circular relationship.  The idea being that for any given project we could run it, find anything circular, and also see how linked together any particular pair of classes is, in order to tell if attempting to unlink them is impossible, difficult, or easy.

However, when I started running it on projects that used classes put inside of lvlibs, it started creating massive lists of circular dependencies, most of which were only due to common membership in a lvlib file.  One lvlib had 20 classes in it (lightweight ones with only 3 VIs each) and my little utility claimed that this was 190 (20 choose 2) circular dependencies because they all linked to each other via the lvlib they were in.  One of the reasons we felt it OK to use lvlib files was the "Remove unused members of project libraries" build option that should trim out anything in there that it didn't need.  It's a message sending library with different child classes for different data types, shared between unrelated projects, so any given project might only use 3-6 of them, but it was convenient to put them all in a lvlib together for easy access.  There were other circular dependencies it found that also only existed due to lvlib memberships but that was the biggest offender.

So I guess the real question is, if I want to reduce EXE build times, should I ignore circular dependencies that only exist due to lvlib memberships (since a lot of them will get removed by the Application Builder since that option is checked, or for other reasons)? 

Or are there subtleties to it... maybe lvlib memberships don't increase EXE build time/complexity as much as classes?  And if it shouldn't ignore lvlib memberships, does class inheritance relationships in a lvlib affect build times more, less, or equal to unrelated classes?

[Darren]

If you have two classes in a library, and neither of them call method VIs from each other, this is not a circular dependency. Their membership under the same parent is not a circular relationship, it's a sibling relationship. Same goes for if either or both classes call member VIs from their owning library. This is perfectly fine too.

The circular dependency comes when the two sibling classes call member VIs from each other.

Also, all of what I've said applies to typedefs, which is probably a more common cause of circular dependencies in large EXE builds than VIs. One of the things I try to do is assign a high level owner to typedefs. If there is a typedef that might be shared between sibling classes/libraries, I make sure the top-most library is what owns the typedef, and not one of the child classes/libraries.

[Enrique.Noe]

Hi, I'm working on a new open-source project to inspect and visually represent your LabVIEW code dependencies.

VIPM:

https://www.vipm.io/package/pantherlab_lib_dependency_inspector/
Documentation:

https://pantherlab.github.io/DependencyInspector/

GitHub:

https://github.com/PantherLAB/DependencyInspector

Take a look and let me know if that helps.

Enrique.

PantherLAB

Software Consultant

[raphschru]

---

@Enrique.Noe wrote:

Hi, I'm working on a new open-source project to inspect and visually represent your LabVIEW code dependencies.

VIPM:

https://www.vipm.io/package/pantherlab_lib_dependency_inspector/
Documentation:

https://pantherlab.github.io/DependencyInspector/

GitHub:

https://github.com/PantherLAB/DependencyInspector

Take a look and let me know if that helps.

---

Tested v1.0.0.10 with LV2020 on a moderately complex project (50-100 lvlib-lvclass), the analysis is frequently interrupted by messages like this:

And at the end, it fails with this error:

By looking at the "most common issues", it seems it could benefit from some robustifications, also I wouldn't want my data to be uploaded to an unknown server...

-The diagram should be generated by a local implementation;

-I couldn't say for the characters, but I may have used french accents (à, â, é, è, ê, ë, î, ï, ô, ö, û, ...);

-The tolerance to missing dependencies would be a plus. It is harder to do but not impossible. When you inherit from a big legacy project or are in the process of refactoring a project, it often happens you have some VIs missing.

Regards,

Raphaël.

[IlluminatedG]

Also, this NEEDS to be updated in big bold letters that it's reaching out to an external service and feeding information to it to generate the images. This is 150% a showstopper in my industry and without that notification this could be very very bad™ with regards to regulations such as ITAR.

Note: I've submitted an issue to the repo.

[wiebe@CARYA]

Kroki.io does install locally or in a docker:

Install Kroki :: Kroki Documentation

[paul.r.r]

I've got a medium/semi large sized application (~5000 vis) where the build time jumped from 20-30 minutes to close to 1.5 hours, but this happened after several weeks of development without a new build, so I don't have a good idea exactly when this change occurred. I'm fairly certain my application doesn't have any major circular dependencies (although it is actor framework based and the actor framework and AF debug are circularly dependent on each other so there is at least one). Does anyone know any easy ways to track down potential other causes? When I enable the build log, I see some VIs/classes have very long save times, is this an indication that these are areas that might be causing the issue, or is that not a reliable metric?

Similarly, I'm wondering if anyone has seen build time improvements from putting some of their smaller libraries or things like widely used typedefs into PPLs? As I mentioned this is an AF project, with a fairly large framework that much of my application specific code depends on, so moving the whole thing to PPLs would be a major undertaking - is there a worthwhile benefit to using a few PPLs? Or even just building the actor framework into a PPL?

Example build log

SourceItem[386]
sourcePath:removed
destPath:removed
saveLevel:0x0
saveTime:10027