Jump to content

EvgenKo423

Members
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

1

About EvgenKo423

  • Rank
    LAVA groupie

Profile Information

  • Gender
    Male

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since
    2017

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. @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).
  3. OK, thanks for your effort.
  4. Thanks for such a detailed explanation, Rob! I just played with string array a bit more and wanna share my findings with the others. 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
  5. 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?
  6. 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.
  7. 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?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.