Request Deallocation

[Artem.spb]

Кто-нибудь использует сабж?

dealloc.png (952 байт) 192 просмотра

Я не смог добиться от этой функции какой-либо пользы. Например, если какой-то массив чрезмерно разрастается и начинает сваливаться по ошибке нехватки памяти даже после перезапуска , то помогает только перезапуск самой
Может, есть специфические условия, когда эта функция оказывается полезной?

[dadreamer]

Кто-нибудь использует сабж?

Не использую и никогда этим не пользовался на самом деле.

Может, есть специфические условия, когда эта функция оказывается полезной?

Очень специфические есть.

The only time when Request Deallocation is advantageous is when you have a subVI that has a very large array pass through it and you don't expect to call that subVI again for a very long time (we're talking arrays on the order of a million elements and delays between calls of at least a few full seconds). In those cases, there can be some advantages to going ahead and deallocating the subVI after every call.

(When does the MemoryManager release memory?)
Эта функция - реликт, оставшийся от старых версий . В современных версиях бесполезен в 99% случаев. В до 7-й версии в параметрах среды была настройка "Deallocate memory as soon as possible" (anxiousMemoryDeallocation=TRUE), при активации которой пытался освободить неиспользуемую память после вызова SubVI. Чаще всего в результате этого сильно страдала производительность. Поэтому настройку убрали (+ переименовали ini токен) и сделали отдельный для тех, кому всё же хотелось проводить "тонкую" оптимизацию. Судя по постам на NI.com и Lava таких было не так много.

Every wire can maintain an allocation of the data if the compiler determines that keeping the buffers inflated gives us the best performance. You can force a a subVI to release those allocations at the end of every execution by calling the Request Deallocation primitive, but I REALLY DO NOT recommend this. You’ll kill performance and possibly not save anything as people usually discover their app immediately re-requests the freed memory. Unless you are getting out of memory errors or are a real pro at data flow memory optimization, I recommend that you let LabVIEW do its job to manage memory. Beating LabVIEW and OS memory management generally requires bursty data flow with infrequent but predictable data spikes, where you can teach LabVIEW something about the spikes.

(TDMS Read to DVR - Memory Usage)

Также существует способ не использовать SmartHeap и таким образом повысить эффективность RD: https://lavag.org/topic/17810-memory-de ... ent=132859 Но, к сожалению, это работает только в IDE, и не известно, какие "грабли" вылезут при повседневной работе с (толком не тестировалось).