Polskie Centrum LabVIEW

Czy ktoś może mi wyjaśnić pewną ważną sprawę. Otóż uruchamiam banalny programik załączony poniżej, programik ma generować tablicę 4096x4096 złożoną z liczb rzeczywistych pojedynczej precyzji, a więc, a więc teoretycznie w pamięci powinien zajmować:
4096*4096*4B=64MB
A niestety po jego uruchomieniu zabiera ponad 250MB (mówię o rożnicy pamięci przed wykonaniem programu, ale z otwarty LabView do pamięci po jego wykonaniu). Czy ktoś mi może wyjaśnić skąd bierze się ta różnica i jak ją wyeliminować. Niestety w programie muszę pracować z bardzo dużymi tablicami i rozwiązanie tego problemu jest dla mnie kluczowe. Testowałem program na wersji 2009 i 2010 i wszędzie ten sam problem.

Z góry dziękuję za pomoc, pozdrawiam!

Indicator tablicy przechowuje drugą kopię danych - to znaczy, że w buforze z diagramu blokowego masz 64 MB i drugie tyle na panelu czołowym w indicatorze.

Dzięki za odpowiedź, ale:
1. Czemu skacze o 250MB a nie o 128MB?
2. Jeśli ten plik jest subVI, to muszę mieć indicator jeśli chcę z niego wyprowadzic wartość. Jak w takim wypadku zrobić, żeby nie kopiować dwukrotnie tabeli?

Żeby sprawdzić, ile faktycznie miejsca używa twój program, masz dwa sposoby:
a) Wejdź w VI Properties -> Memory Usage, tam jest to napisane
b) (lepiej) Uruchom Tools->Profile->Performance And Memory..., tam sobie ustaw Profile Memory Usage i Memory Usage.
U mnie wychodzi 134 MB, czyli 2*64 MB na to co powiedziałem, plus 4096*4B na bufor pętli wewnętrznej, plus jakaś tam drobnica.

SubVI ma swój bufor pamięci i tego chyba się nie przeskoczy, ale rzuć okiem na temat VI Memory Usage

Jeszcze zaraz dzięki za odpowiedzieć.
Mam jeszcze w takim razie pytanie do subVI. Jeśli w jednym subVI czytam tablicę z pliku, to juz mam dwie kopie? Bo kopia jest w indicator'ach subVI oraz na diagramie blokowym. Teraz z tego subVI przechodzę do drugiego, który tę tablicę obrabia, więc tam tworzy się kolejna kopia, a może nawet dwie, bo na wejściu są controlki, a na wyjściu indicatory, więc mam już trzy albo cztery kopie. Na koniec idę z tą tablicą do ostatniego subVI, który zrzuca ją spowrotem na dysk, czyli mam rozumieć, że używając tych subVI tworzę 4 kopię tej tablicy?
Jesli tak, to jaki jest sens używania w takim wypadkach subVI, czy nie da się w żaden sposób tego obejść? Zawsze każdy subVI musi stworzyć sobie kopię?

Umm, nie, trochę zmyliłem nawet siebie z tym buforem. W tym linku, który Ci podałem (część "Memory Issues in Front Panels") jest wyjaśnienie, kiedy subVI tworzy sobie kopię danych. Zobacz też tam część "Rules for Better Memory Usage".

A czy w ogóle da się w jakis magiczny zmusić subVI, żeby zwolnił pamięć po użyciu. Mam w programie tak, że jeden subVI służy do wczytania danych i po wczytaniu przekazuje je do kolejnego subVI on nie jest mi już do niczego potrzebny, a jednak jak patrzę na monitorze on nadal alokuje pamięć. Czy można jakoś skutecznie na nim wymusic zwolnienie pamięci?

Podstawowe pytanie brzmi, dlaczego miałbyś to robić, a nie pozwolić LabVIEW robić tego samemu w razie potrzeby. Jeśli zacznie brakować pamięci, to LabVIEW sam sobie ją załatwi z tego co można wyczyścić (czyli np. z subVI). A odpowiadając na twoje pytanie- bloczek Request Deallocation.

Sprawdzam właśnie na monitorze pamięci zajętość i pełna stochastyka zachowań. Oj chyba chłopaki muszą jeszcze troszkę popracować nad obsługą pamięci w LabView;)
A miałbym to robić dlatego, że LabView tego niestety nie robi przy wczytywaniu danych otrzymuję informację, że niestety 3GB pamięci to za mało dla niego, a według moich wyliczeń tablica ma ok. 100MB, więc spokojnie powinna się mieścić, ale jak kazdy z subVI sobie ja w pamięci trzyma, to niestety takie są skutki. Muszę przyznać, że w tym zakresie troszkę mnie LabView rozczarowało, w innych środowiskach nie miałem nigdy takich problemów i dublowania pamięci.

Ja jeszcze raz polecam lekturę tego linka, bo mam kilka podejrzeń co do twojego zagracania pamięci ;) A podglądanie tego co się dzieje w jakimkolwiek zewnętrznym monitorze ma większy sens dopiero po kompilacji i uruchomieniu samodzielnego programu.

A możesz się podzielić swoimi podejrzeniami?

Generalnie, żeby nie robić wielkiej tajemnicy to problem pojawia się w tym subVI, którego załączam. Wczytuje plik binary ok. 100MB, a subVI zajmuje mi ok. 300MB. Nie wiem, gdzie tam może tkwić błąd, zielonego pojęcia nie mam, ale jakbyś miał jakąś ideę, to będę dozgonnie wdzięczny;)

Sorki, uprzedziłeś mnie z postem:P
hmm może przyda Ci się bloczek Programming->Application->Memory Control-> Request Dellocation
Ja jeszcze dorzucę linka:
http://zone.ni.com/reference/en-XX/help ... ringcalls/ <- sposoby wywoływania subvi i ich wpływ na pamięć.

Co do tego kodu to miałbym następujące uwagi:
- Błąd z nieistniejącym plikiem wyprowadziłbym jako error, a nie wyświetlał z poziomu subVI. Po pierwsze to będzie czytelniejsze (obsługa błędów w głównym VI), po drugie- takie wyświetlanie może powodować właśnie umieszczenie całego subVI w pamięci (to tylko podejrzenie, niekoniecznie poparte pewnością).
- Wyprowadzenie danych w postaci jednego klastra też nie jest najlepszym pomysłem - każesz LabVIEW zaalokować tak naprawdę jako jedną całość potężną strukturę. Rozważ wyprowadzenie oddzielnie jako klastra tych wszystkich pojedynczych zmiennych (Xstep, Ystep, itd), i oddzielnie każdej z tych trzech tablic.
- Jeszcze gorsza rzecz w przypadku tego klastra - pojawia się tam czerwona kropka, która zwiastuje nam konwersję danych i przy tym - utworzenie dodatkowego bufora na to działanie.

W klasycznym wywołaniu statycznym SubVI'a Labview zwalnia zasoby VI'a wywołanego (subvi'a), czyli pamięć, referencje, dopiero po zamknięciu VI'a wywołującego (głównego). Proponuje więc przejść na wywołanie dynamiczne - klikamy na SubVI'a prawym myszy "Call Setup" i zaznaczamy "Load and retain on first call".

PiDi pisze: - Jeszcze gorsza rzecz w przypadku tego klastra - pojawia się tam czerwona kropka, która zwiastuje nam konwersję danych i przy tym - utworzenie dodatkowego bufora na to działanie.

Tego nie byłbym taki pewny - kropka najpewniej wynika z faktu zapisu klastra jako Type Def, a niestety Labview ma zwyczaj takiego oznaczania (moim zdaniem wprowadzający troszkę zamieszania), gdy podajemy dane jakiekolwiek inne niż dokładnie taki sam zdefiniowany Type Def.