Jump to content

Should I abandon LVLIB libraries?


Recommended Posts

Something I did not appreciate till today:

 

If I have an LVLIB library in which I use one of its VIs, then any LVCLASS class referred to by ANY of the LVLIB’s members will be loaded into memory (along with all their dependancies).

 

In addition, the fact that all library members show up under “dependanciesâ€, even if only a few are actual used, makes it difficult to get useful information about real dependancies. 

 

So, should I ditch the use of LVLIBs altogether as a hopelessly-flawed tool? 

 

— James

 

Added later: Must be getting old, as I forgot that I already knew this.  But the question remains of what to do about it.

Link to comment

At work we favor packed project libraries for production deployment (VIPM packages for development deployment) so lvlibs are unavoidable for us.

 

But we do run into the "load the earth" scenario too. The best compromise we have found is to break down the component into smaller pieces.

Link to comment

Yeah this "feature" kinda sucks at time.  And I'm a little disappointed that no other posts have been tagged with "things about labview that suck" but whatever.

 

If it makes you feel any better, in the build environment generally these unused dependencies are removed.  In the build specifications under Advanced there is a checkbox for removing unused items.  Then at least they won't exist in your EXE, taking precious loading time.

 

As for the development environment, yeah modulating code helps.  But doing so usually means more VIs in general, which means more dependencies on disk.  I don't find it that bothersome, but if you have 100s of libraries and classes I would be pulling my hair out trying to find a better solution.

Link to comment

Unless VIPM is involved, I Use LLBs instead.

Not trying to change the subject, but I avoid LLBs at all costs.  Every time I find one the first thing I do is extract the VIs from it.  I feel that way because it seems like a zip or an archive, where to use it with the normal tools, I need to extract it anyway.  I also know there were odd bugs a while ago where the LLB would get corrupted and ruin all the VIs in it.  I know that is petty especially since it probably has been fixed long ago, but it still lingers as a thing to avoid in my mind.

  • Like 1
Link to comment

If it makes you feel any better, in the build environment generally these unused dependencies are removed. 

True, but how do I identify real dependancies from all the fake ones?  

Unless VIPM is involved, I Use LLBs instead.

LLBs don’t seem to be equivalent (though I never really used them).  No namespacing, no Private scope.

Link to comment

Not trying to change the subject, but I avoid LLBs at all costs.  Every time I find one the first thing I do is extract the VIs from it.  I feel that way because it seems like a zip or an archive, where to use it with the normal tools, I need to extract it anyway.  I also know there were odd bugs a while ago where the LLB would get corrupted and ruin all the VIs in it.  I know that is petty especially since it probably has been fixed long ago, but it still lingers as a thing to avoid in my mind.

 

They fell out of favour because they hide VIs from source control rather than any bugs or funny behviours. However, VIPM can pack directories into LLBs so it's not that much of an issue anymore for most people (can keep directories for development if its an issue). Your animosity towards them is unfounded :D

Edited by ShaunR
Link to comment

True, but how do I identify real dependancies from all the fake ones?  

LLBs don’t seem to be equivalent (though I never really used them).  No namespacing, no Private scope.

 

Well. If you abandon LVLibs, you will only have a directory of VIs which are very easy to cross link and not as easy to distribute or organise as well as no namespacing or private scope. If you want scope, put them in a class.

 

For dynamic loading plugin distros, LLBs are great because they are monolithic containers that don't load everything into memory unless linked or loaded explicity . For identical to LVLib without the [arbitrary] bits you don't want-probably asking too much.

Edited by ShaunR
Link to comment

Something I did not appreciate till today:

 

If I have an LVLIB library in which I use one of its VIs, then any LVCLASS class referred to by ANY of the LVLIB’s members will be loaded into memory (along with all their dependancies).

 

In addition, the fact that all library members show up under “dependanciesâ€, even if only a few are actual used, makes it difficult to get useful information about real dependancies. 

 

So, should I ditch the use of LVLIBs altogether as a hopelessly-flawed tool? 

 

— James

 

Added later: Must be getting old, as I forgot that I already knew this.  But the question remains of what to do about it.

 

I'd say your lvlibs are probably too big. I tend to consider them to be a single API, not a library of many APIs. This matches well for the features of the lvlib. For example, I can add a icon overlay as part of the lvlib file. If I have too many things I can't make a single good icon. Everything in the lvlib should be something you want to be loaded atomically, in my opinion. I'm not sure what I would do in situations where the stuff in the lvlib is not an API I want to use.

 

All that having been said, I've never really used the dependencies for anything except to get to parent classes and the like, so I'm not sure what sort of filtering you want to do on that information. But I would also say that keeping dependencies in lvlibs makes your dependencies organized -- you don't have 1000 stray files from VI lib, you have 5 classes and 5 lvlibs.

 

In fact, I have the reverse problem you have. Since labview counts things in lvlibs as dependencies but doesn't necessarily load them into memory, things like find and replace or "show error window" don't actually work on them unless you manually open the front panel of every VI. 

Link to comment

Everything in the lvlib should be something you want to be loaded atomically, in my opinion.

 

Is that wise?  What if your API optionally interacts with some other API, and you have optional methods to support easy interoperation.  It’s possible that a particular programmer my want to use one or the other APIs by themselves.   Where do the optional VIs that depend on both go?

 

An example might be: I have a message-passing API, and a TCP API, and I want to pass messages by TCP sometimes, without tying these two APIs forever together?  And without having the extra burden of stewarding LabVIEW to do the obvious: don’t load it it it isn’t used.

Link to comment

Is that wise?  What if your API optionally interacts with some other API, and you have optional methods to support easy interoperation.  It’s possible that a particular programmer my want to use one or the other APIs by themselves.   Where do the optional VIs that depend on both go?

 

An example might be: I have a message-passing API, and a TCP API, and I want to pass messages by TCP sometimes, without tying these two APIs forever together?  And without having the extra burden of stewarding LabVIEW to do the obvious: don’t load it it it isn’t used.

Fair example. I tend to end up making simple interface classes for this situation but I know they aren't for everyone. Ideally I would have 3 lvlibs. A would be the messaging component, B would be the tcp component, C would just contain the set of functions which tie them together. I'm doing something similar with a file loader right now. I want a generic hierarchy of essentially key value pairs so that the lowest level component can be used everywhere. In the actual application I'm trying to write I have a file loader which loads my particular hierarchy which includes a system configuration object that contains N process objects which contain M plugin objects. So now that I've gotten the two libraries where I wan them, I'm writing a 3rd library which converts between the very generic hierarchy and the specific hierarchy, as well as allowing for some useful manipulations of the data set (lets say I only want to load process #4 and its plugins, but not the rest of the system).

Edit: Its worth mentioning that while this is something I am definitely doing, I'd probably simplify it if I were writing from scratch -- I'm trying to refactor months of work so it can be used on a few different projects, which is why having these weird dependency links is currently desirable.

 

Downsides to this are that it can't always work (but usually works enough for me to not worry about using lvlibs) and it does lead to occasional instances of bloat and situations where I have to convert between the types used by the different libraries, but it seems to work well enough for my purposes.

  • Like 1
Link to comment

Fair example. I tend to end up making simple interface classes for this situation but I know they aren't for everyone. Ideally I would have 3 lvlibs. A would be the messaging component, B would be the tcp component, C would just contain the set of functions which tie them together. I'm doing something similar with a file loader right now. I want a generic hierarchy of essentially key value pairs so that the lowest level component can be used everywhere. In the actual application I'm trying to write I have a file loader which loads my particular hierarchy which includes a system configuration object that contains N process objects which contain M plugin objects. So now that I've gotten the two libraries where I wan them, I'm writing a 3rd library which converts between the very generic hierarchy and the specific hierarchy, as well as allowing for some useful manipulations of the data set (lets say I only want to load process #4 and its plugins, but not the rest of the system).

Edit: Its worth mentioning that while this is something I am definitely doing, I'd probably simplify it if I were writing from scratch -- I'm trying to refactor months of work so it can be used on a few different projects, which is why having these weird dependency links is currently desirable.

 

Downsides to this are that it can't always work (but usually works enough for me to not worry about using lvlibs) and it does lead to occasional instances of bloat and situations where I have to convert between the types used by the different libraries, but it seems to work well enough for my purposes.

 

A comment on smithd's description of "package management" with lvlibs - this type of management is common in our other Java and .NET applications for packaging dependencies. Discussions around how to manage packages in order to reduce dependencies / coupling between dependencies has been a common topic of discussion in the development world (outside of LabVIEW) for many years now. LabVIEW has it's own take on the same concepts. We typically try and use the "stairway" pattern for dealing with dependencies but that relies heavily on LabVIEW "interfaces/abstract" classes. It works most of the time; on occasion we have the same sort of bloat but that typically occurs when we have multiple copies of basically the same dependency loaded from different packages.

  • Like 1
Link to comment

So, should I ditch the use of LVLIBs altogether as a hopelessly-flawed tool?

 

I did.

 

(That is, after years and N00's hours investigating LVLIBs in the context of namespacing/distribution/building/linking/encapsulation/scoping/reuse/load time/dependency management and so forth. James, I am not surprised if you independently draw the same conclusion, and I'm interested to hear if you conclude otherwise.)

  • Like 2
Link to comment

I did.

 

(That is, after years and N00's hours investigating LVLIBs in the context of namespacing/distribution/building/linking/encapsulation/scoping/reuse/load time/dependency management and so forth. James, I am not surprised if you independently draw the same conclusion, and I'm interested to hear if you conclude otherwise.)

 

Do you favor LLBs as the alternative? I'd be interested in hearing more of how you manage the same use cases.

Link to comment

Massive no from me on LLBs. I do not need to distribute my code like that, so really have no purpose for them. As others have pointed out, no namespacing, no access scope makes these a stale technology (for my situation at least) in LabVIEW.

 

 

I still do use libraries though (and classes of course, which are also libraries), even with all the pain associated with the loading the entire contents etc. It troubles me too much me to have to manually namespace every VI, so I am not sure I will move away from libraries or some form of them any time soon.

Link to comment

Food for thought:

If huge amounts of analysis and tribal knowledge is required to not write bloated, unscalable and buggy code with a certain tool. Is it not a better strategy to just not use that tool?

 

Those outcomes are possibilities, not guarantees. Not every application has 8000 VIs, and in a lot of situations the careful use of libraries can be really beneficial.

 

I am not ready to give up on them yet.

Link to comment

You are skirting around a couple of fundamental issues, not directly to do with LVLibs but with LVPOOP and are the reasons why LVLIbs fall short of expectations.

 

Isn't that upside-down? LVClasses are specializations of LVLibs, so they inherit the strengths and weaknesses of LVLibs, not the other way round.

 

If LVLibs are improved, then LVClasses will automatically gain those improvements too.

 

 

2. A function per VI is a purely semantic imposition for dynamic dispatch.

 

If I've understood Jack's point correctly, the issue is that the one-function-per-VI system significantly increases the number of files in a project. This increases the effort required to write and refactor code (all LabVIEW code, not just LVClass code). This also amplifies the lags caused by widespread static linking.

Link to comment

You are skirting around a couple of fundamental issues, not directly to do with LVLibs but with LVPOOP and are the reasons why LVLIbs fall short of expectations. I think you have seen and hinted at, but not articulated, though.

 

1. it is impossible to create LVPOOP components with zero static linking (this is trivial with an open VI and a LLB full of functions which can be loaded and unloaded dynamically).

 

It's tenable at worst, desirable at best, for an LVCLASS and its members to be statically-linked. Any desire otherwise could be an indicator of class design or object model that could use refactoring, or a desire for more appropriate language facilities (more on that later).

 

For an illustrated example, here's one annotated section of the diagram above:

 

post-17237-0-81410800-1417186519.png

 

The top arrow shows methods from a third-party hardware driver that are required by the application, the middle arrow is very likely an LVCLASS or LVLIB, and the bottom arrow shows unreachable, unused dependencies -- portions of the hardware API that bloat the application.

 

Although not ideal, this scenario of roughly ~30 unused source files may not be measurably bad. The birds-eye view of this application indicates ROI of refactoring this class probably isn't justified. Though, used in another application, that exact same library could cause problems (such as even further unwanted linkages, perhaps even some that break the application with unsatisfied dependencies such as uninstalled packages or platform-specificity).

 

Different application space yields different polarizing filters through which we choose tradeoffs. As library designers, it's worthwhile to consider our responsibility to enable our developer-end-users, and explicitly avoiding designs which cause them heartache.

 

--

 

I wasn't going to bring up Inheritance as another type of static linkage best cut with our figurative link scissors, but it's now relevant in the context of LVOOP. Inheritance, in and of itself in any language, represents a code smell worth investigating.

 

But... Inheritance! Dynamic Dispatch! This example demonstrates precisely the value of traits/mixins in an OOP language. With traits/mixins, we can achieve all desirable outcomes discussed above in terms of higher cohesion and looser coupling (and re-use!), by eschewing 1) suboptimal/incorrect inheritance hierarchies, and 2) classes that do too much, even if there appears "good reason" for the monolithic library (Hardware APIs for LabVIEW are notorious for wrapping serial protocols as one-command-per-VI in monolithic libraries. There are thoughts/considerations of dynamic versus static programming as another solution, but that's another thread).

 

Lacking Mixins in LVOOP, Inheritance sometimes is workably sufficient to describe and implement the real-world, but oftentimes it can't. Again, to be fair, it's healthier to focus on measurable negative value than pedantry, and oftentimes it's workable to incur these tradeoffs introduced by inheritance.

 

@ShaunR, for this reason, I don't think LVCLASSes fall short in the way you might be describing. (Except for one debatable behavior in the IDE, where all classes in a hierarchy are broken if one is, and where the explanation as to why in that link is tenuous, where the more desirable behavior is to throw run-time exception in the scenario presented in that link) The way that LVCLASSes fall short is by lacking Mixins, which provide targeted and precise linkages to atomic units of relevant code.

 

(for clarity, regardless whether industry is landing on the term Trait or Mixin, I support the construct that also provides extension of mutable state, not just method implementations, and certainly not just interfaces with no implementations. I think "Mixin" is most appropriate, its distinction from "Trait" being "Trait" might not connote further extension of state)

 

 

it is impossible to create LVPOOP components with zero static linking

 

tl;dr The design goal when designing an LVOOP object model is not necessarily to avoid all static links, but rather to intentionally design dependency vectors, especially recognizing and avoiding anomalies and incidental linkages that have detectable negative value. And, LVOOP needs Mixins.

  • Like 1
Link to comment

@ShaunR, for this reason, I don't think LVCLASSes fall short in the way you might be describing. (Except for one debatable behavior in the IDE, where all classes in a hierarchy are broken if one is, and where the explanation as to why in that link is tenuous, where the more desirable behavior is to throw run-time exception in the scenario presented in that link) The way that LVCLASSes fall short is by lacking Mixins, which provide targeted and precise linkages to atomic units of relevant code.

 

Sorry Jack. Everything will be fine if only we had X,Y Z is just adding more goo to a sticky mess. I think this discussion needs to be taken to another thread so as not to derail the OP (any further?) as there are some very simple premises here that are being conflated.

Edited by ShaunR
Link to comment

Food for thought:

If huge amounts of analysis and tribal knowledge is required to not write bloated, unscalable and buggy code with a certain tool. Is it not a better strategy to just not use that tool?

 

To carefully dereference "certain tool", if that refers to LVLIB, yes -- it's worth considering whether this tool belongs in our toolbox.

 

If "certain tool" dereferences to LabVIEW -- LabVIEW as a language is excellent and certainly not worth abandoning. Conversely, it's worth considering if you're not already using it. LabVIEW has rooms for significant improvement, but its syntax is currently unparalleled in programming, period.

  • Like 1
Link to comment

Awesome chain of discussion guys.  Sorry OP if this is derailing the conversation but I think it still is relevant to the original question.

 

Making and using polymorphic VIs is a major pain point for several reasons.  And from a reuse stand point there isn't many other options.  Replacing polymorphics with XNodes (if every officially supported) I think would help because you replace the 40+ instances with a custom scripted VI.  No idea if it scales well.  Jack you mentioned replacing polymorphic VIs with their instance.  In my mind this is something that could be done quite easily with scripting for a while project.  This could be a VI that is ran periodically, possibly as part of the Pre-Build VI that could help clean up the project.  Did you ever make this scripting VI?  Could you see sharing it if you ever did?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.