Leaderboard

Crud. I replied to this, but it never showed up in the feed. Huh. Anyway, yes, I'm turning this over to one of our C folks to deal with. I'm not sure if I can get the .NET version past our Information Assurance zealots, but a regular old dll I can call with a CIN will be fine.

Yup we were trying to be positive. I have not experienced too many crashes involving classes lately although I do purge the mutation history every few weeks (No problems with a medium size project including approx 85 classes).

Here are my results (Windows 7, LabVIEW 2015 32-bit): path constant average: 13.515us no path constant average: 13.437us path from control on front panel average: 13.958us (an attempt to simulate the V0.0.2 implementation) CLNbenchmark.vi

About 600-800us if memory serves. For Linux I opted for a symlink to the *so if it's not on the search path. If you try to load a *so from the local directory and there is another elsewhere on the search path; you normally end up with crashes. Linux handles dynamic loading poorly which I suspect is why most people statically link.

In terms of CPU there is definitely less resource consumption by an invisible control, quite independent on how it was made invisible (made invisible, on an invisible tab, window minimized or hidden). In terms of memory resources there is not really any difference, the control still is there and needs to manage its state and data. This also means that it is not 100% idle. If you change properties, or the value in any way, it will take some processing power to update the internal state of the control even if it is invisible. However this is typically significantly less of an effort than even just updating a single numeric control on a front panel. YMMV of course, updating a graph with a multi mega samples array will take some time as the data may have to be copied into a new data buffer, but the drawing of invisible controls is postponed until they get visible again (if LabVIEW knows that the control is invisible, that might be different for a control that is on a technically visible panel but outside of the bounds of your screen).

Maybe that is an output only argument to mupGetExprVar? It would make little sense that the call sequence has a completely transparent argument. In any case, have you noted the shift register for that pointer? This should keep the case of N=0 exprs from crashing. Apropo which, mupGetExprVars still crashes if called with Parser in=0, that should perhaps be trapped in a production version. yes. Probably sloppiness of the author who didn't push the version number everywhere (I added the X32 and X64 in the names on my own, though). About the choice of the library, I'm still thinking at the best strategy for muLibPath.vi. If one puts more complex path logics into it, that affects very badly performance, as the VI is called for every single CLN. Probably the best is to make an inlined VI out of it, containing only a single path indicator, whose default value is assigned once for good by an installation script. I hope that the compiler is then able to optimize it as a hardwired constant.

Debugging off, I realized that it is for inlining; compiled code, I downloaded your first commit on LAVA rather than the latest github. 2015, please: mupLib.zip If ever useful: libmuparser.zip compiled .so for X32 and 64 on ubuntu16. As they are dynamic, I doubt they may be themselves dependent on some other system lib, and hence particular of that distro. I'd also think at a benchmark which iterates on repeated open/evaluate/close. I see it as a frequent use case, and suspect that muparser might do better than the formula parser there.

Cracked it finally. You were passing the wrong pointer to DSDisposePtr. Here mupLib-path.zip is a corrected version of the whole lvlib. Now all examples and benchmarks run for me in LV2017 32&64, 64bit being marginally faster with the default eq in the benchmark

Note that there are two schools-of-thought on how to use User Events. One is to have a separate custom Event for every different message (about 40 in your case). For examples of this see the DQMH or JKI’s “State Machine Objects”. These rely on scripting tools to manage all the custom subVis that need to be generated. The other school is to use a single User Event to carry all messages, using something generic like a string “message label” and a Variant “data” payload. “Messenger Library”, if you look under the LVOOP hood, is basically this. At its simplest, you can do this later method with only a single “Send Message” subVI (with “label” and “data” inputs) that you place everywhere you were previously setting a control. So this is not a lot of work, or at least, not more than any other possible method.

Take a look at drjdpowell's Messenger library (available in VIPM). I believe the demo shows an example of how to do what you want. Its relatively easy to learn the basics, and its even more powerful under the hood.