Na koniec polecam wszystkim przeciwnikom zrobić mały test: wyrysować pokolorowany tekst (tak jak na statusie blipa gdzie pokolorowane są tagi, linki, użytkownicy) przy pomocy DrawString a potem zrobić płynnego scrolla po ekranie.

Usuwanie tego cache i tworzenie go na nowo też nie wydaje się do końca dobrym pomysłem.
Garbage Collector w .NET CF jest dość prymitywny – nie śledzi dziur w stercie które powstają w wyniku niszczenia obiektów. Jeśli tworzymy obiekty A B i C sterta wygląda w przybliżeniu tak: |A|B|C| Jeśli teraz zniszczymy obiekt B i utworzymy D to sterta wygląda tak: |A| |C|D| itd. Jedynie raz na jakiś czas GC wykonuje tzw. heap compaction, gdzie przeczesuje całą stertę w poszukiwaniu dziur a następnie przesuwa wszystkie obiekty po stercie tak, żeby nie było dziur – a to jak wiadomo strasznie czasochłonna i zamulająca operacja. Chyba jeszcze gorsza niż rysowanie tych tekstów DrawString()-iem. Ale do tego trzeba by wykonać więcej testów.

Faktycznie nie napisałem jak mierzyłem i na jakim sprzęcie, bo tak jak napisałem we wpisie chodzi mi o proporcję a nie konkretne wyniki.
Masz rację, że w przypadku “bardzo” dynamicznego tekstu, który często się zmienia cache jakikolwiek nie ma sensu. To jest przykład cache dla tekstów które się rzadko zmieniają i wbrew pozorom zużycie pamięci nie skacze dramatycznie jeżeli użyje się go “z głową”.

Dziękujemy za publikację – Trackback z dotnetomaniak.pl…