Narzędzie do analizy użycia pamięci

Cześć!
Szukam narzędzia, które pokaże mi powód, dla którego aplikacja zżera sporo pamięci. Sprawdziłem aplikację pod kątem wycieków pamięci. Idealne narzędzie powinno pokazać mi nazwy typów, liczbę instancji danego typu oraz rozmiar.
Zapoznałem się z tym tematem http://stackoverflow.com/questions/9720943/how-to-analyze-excessive-memory-consumption-pagefileusage-in-a-delphi-applicat/
Ściągam AQtime, aby sprawdzić, czy mnie usatysfakcjonuje.
Próbowałem użyć VMMap, lecz dostarcza za mało informacji.
Nie mam za bardzo doświadczenia w tym zakresie, aplikacja jest dość duża, dlatego chciałbym uniknąć babrania się w źródłach.

EDIT: Aplikacja jest stworzona przy użyciu Delphi 7. Jednak minimalnym nakładem pracy mogę również odpalić ją na XE2.

Idealne narzędzie powinno pokazać mi nazwy typów, liczbę instancji danego typu oraz rozmiar.

Bodajże w nowszych Delphi jest coś takiego jeżeli chodzi o wycieki.

Ściągam AQtime, aby sprawdzić, czy mnie usatysfakcjonuje.

Najpierw pytam, potem szukam. Genialne.

Próbowałem użyć VMMap, lecz dostarcza za mało informacji.

Zdefiniuj za mało.

Nie mam za bardzo doświadczenia w tym zakresie, aplikacja jest dość duża, dlatego chciałbym uniknąć babrania się w źródłach.

Powodzenia. Może chcesz żeby samemu ci kod poprawiło? Debugger też powinien od razu sam poprawiać kod. A IDE pisać cały kod po wciśnięciu pierwszej literki.

Szukam narzędzia, które pokaże mi powód, dla którego aplikacja zżera sporo pamięci.

Zdefiniuj sporo.

-123oho napisał(a)

Najpierw pytam, potem szukam. Genialne.

Informacji na ten temat szukałem zanim tutaj napisałem. To, że zaraz będę sprawdzał kolejne narzędzie(kobylaste jak cholera) po kilku już sprawdzonych, nie znaczy, że ktoś nie zna lepszego sposobu.

-123oho napisał(a)

Bodajże w nowszych Delphi jest coś takiego jeżeli chodzi o wycieki.

Nie wiem, ale odpowiadam - genialne. W XE2 jest narzędzie dostarczane z FastMM - FastMMUsageTracker - pokazuje tyle info ile VMMap(o tym niżej).

-123oho napisał(a)

Zdefiniuj za mało.

Nie podaje informacji o zaalokowanych typach oraz ich rozmiarach. Podaje adresy zajętych bloków pamięci oraz ich rozmiary

-123oho napisał(a)

Powodzenia. Może chcesz żeby samemu ci kod poprawiło? Debugger też powinien od razu sam poprawiać kod. A IDE pisać cały kod po wciśnięciu pierwszej literki.

Inne posty kolegi w podobnym tonie widzę:) Źle się wyraziłem - kod oczywiście przeanalizowałem, jednak nie mogę doliczyć się ilości danych za chiny.

-123oho napisał(a)

Zdefiniuj sporo.

500MB, gdzie szacunkowo powinno być 150-200.

Nie podaje informacji o zaalokowanych typach oraz ich rozmiarach. Podaje adresy zajętych bloków pamięci oraz ich rozmiary

Nie podaje rozmiarów ale podaje rozmiary. Tak wiem o co ci chodzi, ale brzmi to bez sensu. Jeżeli liczysz na więcej niż adres i rozmiar to powodzenia, bo normalnym ludziom to wystarczy... Normalne reporty takie coś obejmują + stack alokacji ew. dealokacji (jeżeli zwolnione częściowo). I czego tutaj więcej chcieć, bo nie rozumiem? No chyba że jesteś pseudoprogramistą który liczy na to że mu wyświetli co ma zmienić na co albo najlepiej samemu poprawi. Bo z tego co mówisz coś takiego wynika.
Jak masz aż takie problemy żeby to znaleźć to użyj jakiegoś nowszego Delphi, tam jakiś system wykrywania wycieków jest dodawany, a FastMM bodaj jeszcze lepsze reporty generuje (ale nie jestem pewien). Skoro to tobie nie pomaga to przerzuć się na np. szydełkowanie..

Inne posty kolegi w podobnym tonie widzę:)

Hehe . Chciałbym żeby było więcej postów gdzie bym mógł nie mówić o szukaniu w google i ganić za głupotę.

Źle się wyraziłem - kod oczywiście przeanalizowałem, jednak nie mogę doliczyć się ilości danych za chiny.

Masz debugger, nie wiem w czym leży twój strasznie dziwny problem... Btw. patrz dalej

500MB, gdzie szacunkowo powinno być 150-200.

Szacunkowo powinno być tyle bo? Tyle mówisz? I btw. patrz wyżej, czy nie wydaje ci się że skoro nie możesz się doliczyć ilości danych to możesz oszacować zajętość w ramie?

Może daj jakiś kod i reporty, jeżeli to nie jest jakieś masakrycznie skomplikowane bo wtedy to się mija z celem.

Chyba źle mnie zrozumiałeś. Nie chodzi mi o wycieki pamięci - tych nie ma(sprawdzone fastMM'em). Chodzi o informację co w danym momencie znajduje się w pamięci. Np. w jakimś typie mam tablicę o bardzo dużym rozmiarze i wiele instancji danego typu.

-123oho napisał(a)

Szacunkowo powinno być tyle bo?

Bo tworzę sobie X(25k) obiektów, sumuję rozmiar pól klasy, wszystkich nadklas oraz mnożę sumę przez X. I rezultaty znacznie się różnią. Dlatego chciałbym się dowiedzieć co pominąłem.

Bo tworzę sobie X(25k) obiektów, sumuję rozmiar pól klasy, wszystkich nadklas oraz mnożę sumę przez X. I rezultaty znacznie się różnią. Dlatego chciałbym się dowiedzieć co pominąłem.

Pominełeś narzut związany z całym system, kodem, a sam TObject też coś waży (i nie jest to tak mało jak się może wydawać).

Chodzi o informację co w danym momencie znajduje się w pamięci.

No to trochę zmienia problem, bo sam nigdy nie miałem problemów z programem który zajmuje za dużo ramu. Debugger powinien pomóc bo mówisz że masz ileś obiektów jakiegoś typu. W każdym razie jeżeli jest ich aż tyle to rosną narzuty chociażby poprzez wszystkie referencje do tych typów (gdzieś trzeba przechować te wszystkie wskaźniki), dodatkowo kod debuggujący może powodować dodatkowy narzut...

Sprawdzałem to przy wyłączonych informacjach debugujących. InstanceSize dla TObject daje 4B(który uwzględniłem w obliczeniach, 4B vtable również uwzględniłem). Możesz rozwinąć swoją wypowiedź dotyczącą narzutów? Na pewno narzuty o których mówisz istnieją, jednak nie sądzę, aby w tym przypadku były jakieś znaczące.

Powiedz czy użycie pamięci rośnie czy się trzyma na tym samym poziomie.

Po utworzeniu wszystkich obiektów użycie pamięci się nie zmienia.

EDIT:
Generalnie w całym moim pytaniu chodzi o polecenie narzędzia do ułatwienia analizy tego zjawiska. Zwyczajnie chciałem oszczędzić sobie zbędnego zachodu, myśląc, że problem jest raczej popularny. W sobotę do tego wracam i najprawdopodobniej czeka mnie zwykła dokładna analiza całego kodu linijka po linijce, czego zwyczajnie chciałem uniknąć bo aplikacja jest dość rozbudowana.