LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Calling .dll from LabVIEW is slow, and seems to leak memory

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.

Download All
0 Kudos
Message 1 of 6
(2,705 Views)

Where is the C code?

 

That is probably where the memory leak occurs.

0 Kudos
Message 2 of 6
(2,690 Views)
I used Labwindows CVI's built in leak detector, and it said that everything had been freed. I've even tried free()ing every pointer, and removing ones that throw the error for freeing memory that isn't malloc()ed. Do you think it still might be a problem? By the way, I learned my C on the street, so please go easy if it isn't great style. This code is based on the pcap library. If you want to run it (a huge thanks to anyone who goes to that much trouble for me), here's instructions on downloading it: First, download winPCap from https://www.winpcap.org/install/default.htm and the WinPCap Developer’s pack from https://www.winpcap.org/devel.htm. Our code was designed for winpcap version 4.1.3 and developer pack 4.1.2. Once the developer pack is installed, unzip it and put the folder WpdPack inside the folder C:\Program Files (x86)\WinPcap.
0 Kudos
Message 3 of 6
(2,663 Views)

Have you tried building just a simple/blank dll and calling that from LabVIEW to see if it produces the same memory/runtime behavior?

Applications Engineering
National Instruments
0 Kudos
Message 4 of 6
(2,630 Views)
For those future users of this forum seeing a similar problem, it wasn't the DLL call. I had a memory leak in a library I was using, and I didn't realize it. The leak checker built in to LabWindows CVI also did not notice the ~1MB that was allocated by a library function as an element of a struct. Don't trust the leak checker, read the fine print of your library's documentation.
0 Kudos
Message 5 of 6
(2,418 Views)

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.

Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 6
(2,404 Views)