Ilość wolnej pamięci RAM dla danych

Zastanawiam się nad implementacją przechowywania danych kolekcji w programie. Jako że użytkownik końcowy może mieć różną ilość pamięci w komputerze, chciał bym spróbować trzymać dane w pamięci w ostateczności na dysku.
Wydaje mi się najsensowniej zrobić to tak, że po uruchomieniu programu sprawdzę ilość dostępnej pamięci RAM i na podstawie tego ustawię globalną zmienną ( powiedzmy w Settings ) na Stream albo dysku albo pamięci. Implementacja klasy ładującej pliki w sumie nie zmieniła by się wcale. Nie wiem jak wielkie dane będą zawierały wczytywane paczki ( przypuszczam, że od 3MB do 128MB jedna paczka ) i ile ich przetrzymać w pamięci.

Pytanie : Jak ustalić ilość miejsca zajmowanego w pamięci przez List<T> ? (marshal.sizeOf(), czy obliczać na podstawie klasy GC. (zapomniałem nazwę metody :( ) )

chciał bym spróbować trzymać dane w pamięci w ostateczności na dysku.

Od tego jest już pagefile, działa samo, nie trzeba nic robić, i na 99% lepiej niż to co zaimplementujesz sam.

Popytałem google i dowiedziałem się, że z poziomu C# nie mam wpływu na miejsce zapisu moich obiektów. Rozumiem, że w twój post mówi mi, że .net sam zadba o zrzucenie moich danych do pagefile ?

EDIT:

O , ciekawą klasę znalazłem : MemoryMappedFile Class.

Rozumiem, że w twój post mówi mi, że .net sam zadba o zrzucenie moich danych do pagefile ?

Stricte zadba o to sam Windows; problem może jednak nastąpić, gdy rozmiar pamięci RAM + rozmiar pliku stronicowania < przewidywany, wtedy po pewnym czasie nastąpi crash tak czy siak.

a .net nie rzuci mi wyjątkiem który mógł bym złapać ? Jeśli tak to gdzie go łapać w WPF -e ?

Rzuci pewno OutOfMemoryException, a złapać go możesz w catch, jak wszystkie inne wyjątki.

Patryk27 napisał(a):

Stricte zadba o to sam Windows ... pewnym czasie nastąpi crash tak czy siak.

Pisałem w tym sensie bo zrozumiałem, że "sam Widnows" i "crash" a skoro to zwykłe wyjątki c# TRY/CATCH/FINALLY to cofam swoje wcześniejsze pytanie.

tylko że w 32-bitowym procesie OutOfMemoryException zwykle nie jest powodowane brakiem RAM-u, a wyczerpaniem przestrzeni adresowej ;-)

no tak, miałem to samo i dziwiłem się czemu nie widzi system 4GB mojej pamięci :)

Tak na marginesie, pod 32-bitowym Windows można dostać się do całego RAM-u (nawet powyżej 4 GB) używając funkcji WinAPI CreateFileMapping i CreateViewOfFile.
Pierwszą funkcją można zaalokować pamięć (duużo pamięci) a drugą stworzyć „okienko” (rozmiar dowolny, byle nie za duży, np. 1GB) przez które widać kawałek tej zaalokowanej pamięci.
Kto pamięta pamięć EMS z czasów DOS-a, to działa to w ten sam sposób ;-)

Mało to przydatne będzie pod C# ze względu na brak placement new, ale można by pobrać wskaźnik do „okienka” wewnątrz bloku unsafe.

w metodzie tworzącej List<T> wrzucę try/catch łapiący out of memory i zdam się na windowa i jego pagefile.

Offtop: a na C64 pamiętam jak część RAM-u była przykryta ROM-em. Aby zapisać dane adresowało się normalnie ale żeby odczytać, trzeba było wyłączać ROM. Takie łatki były chyba od adresu 0000 do 0100 i później z 2 razy znowu. Już nie pamiętam adresów. Trzeba było nieźle się nakombinować umieszczając tam kod.