Leaderboard

Here's a GIF comparing the selection drag + scroll speed on the same large VI in 2018 and the latest 2019 build, both on my dev machine.

I've noticed a lot of slowdowns with LV2017 and LV2018 doesn't seem any better. Also, I use the NI-IMAQ extensively and NI-IMAQ 2018 is buggy and doesn't seem ready for widespread use. I've been trying to deal with these massive slowdowns with LabVIEW 2017 for over a year now and it has really slowed down development for me. I too have issues scrolling (I have the same 2Hz refresh rates sometimes, but then it seems to mysteriously go away), slow window drags, slow selection dragging, etc. and have contacted NI technical support about this but since I can't provide my project, haven't gotten far at determining cause or solutions. Why does it seem that nobody at NI is concerned about this behavior?

From time to time, albeit sporadically, I have to build wrapper sets to .dll and .so, and I would love any improvement. Back in the days I was used to have to write my wrapper VIs one by one, and by now, especially for large libraries, the import wizard is a lifesaver to me. However, I end up still spending some amount of time, often significant, domesticating the .h files provided with the libraries so that the wizard sees better through them, writing LV translators between C structures and casted down byte arrays, creating ad hoc enum ring typedefs, hunting untranslated pointers, and similar chores. If that could be automated, I would enjoy it, though I agree that beyond some point that becomes project-specific. And at times (callbacks, message pumps i.e.) still no choice but having to write C containers. Have btw the import tool parsing capabilities got any better across versions? (I vaguely think yes but I don't have fair data for a comparison)

LLVM/Clang is truly a marvel! If you need to write wrapper VIs for DLLs, then I think a tool like this is the way to go. However, unless the C API has anything non-trivial like passing a large struct by-value or strings/arrays, you'll end up having to write your own wrapper DLL, right? (side note: I do wish LabVIEW would let us pass Booleans straight into a CLFN by-value...) This struct has the same size as a single int, so you can lie to the CLFN: Say that the parameter type is a plain I32. What are the possible types in the union? If they're quite simple and small, you could tell the CLFN to treat it as a fixed-size cluster of U8s (where the number of cluster elements equals the number of bytes of the union), then Type Cast the value to the right type. The type cast will treat your cluster as a byte array). These would require project-specific scripts that don't fit in a generic automatic tool though. The import wizard was useful for study purposes, to figure out how I should create my wrapper (using a simple sample DLL). That was about it.

Also, this is kind of a side point but the concept is the same. Has anyone noticed that reentrant VIs get super slow sometimes when debugging? Its not always, but I can't figure out what conditions might be causing it. Its like you're going along debugging some code, you step into a reentrant VI, and everything just stops, and it takes like 20-30 seconds for the window to materialize. I know its not just one computer, sadly.

That is very unfortunate. NI really needs to work on that. For reference, I found a complex VI here and used that on my private notebook (decent hardware, enough for LV2015). This is what it looks like on my end (using LV2017.0f2). 2019-02-01 20-59-05.mp4 It's a bit faster without recording of course, but not much. Also the CPU consumption is about 20% while dragging, which is way to high in my opinion. How did that ever pass testing phase? Looks to me like they never tested with more complex VIs like this because it works fine for smaller (or empty) VIs. Anyway, it seems that the dragging operation in LV2017 is not a O(1) operation. More like O(n) where n is the number of objects on the block diagram. They probably check every object during the drag operation to figure out which one to highlight. Works better on the front panel but that is probably because there are less objects on the FP (i.e. no wires).

Wait, what about the person who already had the name Bryan?