11-15-2018 07:07 PM
I have a .dll that I made in LabWindows CVI which I'm calling from LabVIEW. The VI and .h file are attached.
My first problem is time. When I run the .c code as an .exe in debug64 mode in LabWindows CVI, the function takes ~1ms. I would expect the function to take less time when it's switched to a .dll, becuase it's a release64 build. However, the VI (which is not much more than a wrapper on the .dll call) takes 150 ms or more.
My second problem, which might be related, is a possible memory leak. I notice that when the VI is run over and over again, it slows down (150ms-250ms over the course of a couple hundred runs). When I look at LabVIEW's memory usage in task manager, it seems to increase by 8 kb every time I run the VI. I'm not sure of this, because there's also a fair amount of natural variation, but I don't notice the change when I run a similar VI that doesn't call a .dll. I used LabWindows CVI's built in memory leak checker, and it didn't find anything.
Does anyone know what might be causing these problems? Is the speed just a natural fact of calling a .dll from LabVIEW that I'll have to get used to?
I used the LabVIEW wizard for creating sequences that call .dll's, but I've since edited that VI somewhat to better interface with external applications.
I appreciate any solutions, advice, or unfounded hunches.
11-15-2018 07:55 PM
Where is the C code?
That is probably where the memory leak occurs.
11-16-2018 01:02 PM - edited 11-16-2018 01:06 PM
11-19-2018 12:16 PM
Have you tried building just a simple/blank dll and calling that from LabVIEW to see if it produces the same memory/runtime behavior?
03-18-2019 10:25 AM
03-21-2019 06:40 PM - edited 03-21-2019 06:41 PM
The leak checker only can check memory allocations that are done through the LabWindows CVI memory manager functions. Your external library calls its own memory allocation functions, maybe the C runtime functions malloc/free, maybe the Windows Heap API functions directly, and maybe some other 3rd party Heap manager functions the developers chose. The LabWindows Leak check can’t even start to guess how your library allocates its memory and therefore has no way to properly hook into that memory manager.