EvgenKo423

On 5/31/2018 at 8:04 PM, jacobson said:

Full crash dumps can be very large and not only will crashes generate full dumps but all DWarns will create full memory dumps so the LVInternalReports folder will get pretty enormous in most cases.

Just wanna add to the topic that you can disable dump creation for DWarns by placing the following key into the INI file:

NIERMaxDWarnDumps=0

@dadreamer, nice find!

Apparently these private properties should do exactly what you want: control SH behavior, but they allow to only control the size of large blocks (which shouldn't be the root of this problem) and don't seem to make any difference in my test anyway.
Library replacement, on the other hand, eliminates this problem completely, even for blocks <256 bytes.

Edit: Selective Deallocation is also available as an INI key along with a key "overanxiousMemoryDeallocation" (which doesn't help either).

OK, thanks for your effort.

Thanks for such a detailed explanation, Rob!

I just played with string array a bit more and wanna share my findings with the others.

15 hours ago, rob.dye said:

These _freed_ blocks are not "lost". SmartHeap knows where they are and will let us use them again, although because they are small SH keeps them in special low-overhead pools that are used _only_ for small allocations, and who knows when LV will need 10M small blocks again. 

These _freed_ blocks were formerly the 10M strings with one "space" character in them, each of which actually take up probably 40 or 48 bytes. Each string block has a LV-managed 32 byte header, plus a 4 byte length, plus 1 byte for the "space" char. LV asks Smartheap for this 37 byte block, and they probably give us a 40 (rounded up to multiple of 8?) or 48 (rounded up to multiple of 16?) byte smallblock to contain our request. Small blocks in SH are low overhead because they only require a single bit to represent their inUse state and require no header of their own.

According to SmartHeap specs, small should be considered blocks under 256 bytes, but LabVIEW starts to release memory as expected only for blocks which are 1048356 + 36 = 1048392 (1 MiB - 184) bytes in size and above. Is it still an expected behavior for LabVIEW?
Anyway, even 256 bytes is probably quite big length for a typical string to get properly garbage-collected.

TestStringArray.vi

Unfortunately, it's still not fixed in LV 2018 SP1. Didn't check it specifically in 2020, but I guess it's the same.
I wonder what happened to this CAR?

Ok, here's a solution for those searching by errors as well:
Here is a link to discussion about 64-bit support for OpenG ZIP Library and here is a link to apparently latest beta build with 64-bit support.

Recently I've installed the OpenG Toolkit v4.0.1.9 on LabVIEW 2018 x64 on Windows 8.1 through the VIPM. When I try to use it, namely ZLIB Inflate / Deflate Vis, I get an error saying "SubVI 'ZLIB Inflate__ogtk.vi': SubVI is not executable". When I open it and select Configure... on Call Library Function node in a Library name or path field I see "C:\Work\OpenG\opengtoolkit\lvzip\source\lvzlib.*".
The same thing with Vis referencing ogportio.dll.

Am I supposed to update them manually before first using them? I didn't find any info about this problem.
Edit: Ok, when I try to update it LabVIEW says it's not 64-bit compatible... Any progress in this direction since 2010?