Cześć wszystkim,
Mam problem z którym nie mogę sobie poradzić. Napisałem program obsługujący odczyt podglądu kamery, na który następnie nakładane 2 (w części przezroczyste) obrazy PNG, które przesuwać można w obrębie podglądu z kamery. Nie mogąc sobie jednak poradzić z wyciekiem pamięci zostawiłem problem dla GC, który uruchamia (automatycznie) się po zajęciu pamięci w okolicach 2000MB. Sprawiłem by po zajęciu 1000MB - GC dodatkowo uruchamiał się z licznika.
Ten sam program uruchomiony na malince (Windows 11 ARM) powoduje wywołanie GC już po 100MB zajętości pamięci... dlaczego? Czy wynika to z ilości dostępnej całkowitej pamięci (32GB vs 8GB)?
0
0
Zależy od posiadanego RAM siłą rzeczy, na pewno jakieś defaltów maszyn wirtualnych na większe / mniejsze architektury, tez bym się spodziewał.
Malinka to 32 bit czy 64 bit ?
GC się nastraja
Ale podrzucę ci inną ideę do sprawdzenie.
W pakietach graficznych często trzeba zwalniać zasoby graficzne a nie tylko RAM, w C# myślimy o using
0
Conditions for a garbage collection
Garbage collection occurs when one of the following conditions is true
-
The system has low physical memory. The memory size is detected by either the low memory notification from the operating system or low memory as indicated by the host.
-
The memory that's used by allocated objects on the managed heap surpasses an acceptable threshold. This threshold is continuously adjusted as the process runs.
-
The GC.Collect method is called. In almost all cases, you don't have to call this method because the garbage collector runs continuously. This method is primarily used for unique situations and testing.
0
ZrobieDobrze napisał(a):
Zależy od posiadanego RAM siłą rzeczy, na pewno jakieś defaltów maszyn wirtualnych na większe / mniejsze architektury, tez bym się spodziewał.
Malinka to 32 bit czy 64 bit ?
GC się nastrajaAle podrzucę ci inną ideę do sprawdzenie.
W pakietach graficznych często trzeba zwalniać zasoby graficzne a nie tylko RAM, w C# myślimy ousing
Malina to 64bit
Czy mógłbyś rozwinąć: "W pakietach graficznych często trzeba zwalniać zasoby graficzne a nie tylko RAM"
...a z czego wynika fakt, że po zakończeniu programu ten zostaje dalej widoczny w Managerze zadań?
1
Neosphoros napisał(a):
W pakietach graficznych często trzeba zwalniać zasoby graficzne a nie tylko RAM, w C# myślimy o
using
jeśli program operuje bezpośrednio na ekran, MUSI pobierać od systemu kontekstu, na Win API są CDC, Font, Brush (czy to, co zwane jest czasem w bibliotekach Canvas) i kilka innych - i ma je symetrycznie zwolnić. Kto uoprawiał Win API, wie.
Wydawać by się mogło, że jak pracuje na wyjściu na plik , to nie zachodzi. No nie do końca, np może pobrać od systemu Font aby na bitmapie napisać tekstem.
Oczywiście nie każdy program jest tak skonstruowany
Widziałem program biznesowy .NET, który po kilku tysiącach wytworzonych plików / dokumentów, rzucił wyjątkiem z CDC w treści, i było to powtarzalne. A nie pracował z ekranem czy rzeczywistą drukarką
Zasob to w teorii coś innego niż RAM, ale hipotetycznie wyobraźmy sobie że troszkę obiektów GC trzyma aż do ostatecznego zwolnienia zasobu.
Więc moja gawędę o zasobach traktuj jako coś obok pracy GC, to coś innego. Ale przegląd usingów zawsze się przyda. Środowiska z GC przyzwyczają nas do powoływania i zapominania o nich, nie do końca słusznie w przypadku zasobów
1
Neosphoros napisał(a):
Nie mogąc sobie jednak poradzić z wyciekiem pamięci zostawiłem problem dla GC, który uruchamia (automatycznie)
Błąd, to nie wyciek pamięci, jeśli pamięć będzie wyczyszczona przez gc https://pl.wikipedia.org/wiki/Wyciek_pami%C4%99ci .Alokowanie pamięci i liczenie, że GC ją wysprząta to standardowa praktywka w języku z GC takim jak C#
Co do problemu: szukaj pod hasłem C# gc tuning. W takiej Javie (myślę, że analogicznie w C#) możesz na wiele różnych sposobów sterować parametrami gc np. możesz zmniejszyć szyczytowe użycie pamięći kosztem częstrzych cyklów GC a więc i zwiększonego użycia CPU.