[fpc-pascal] Is such memory statisticspossible?

[Ludo Brands]

These are useful additions, thanks. I suppose the limit automatically solves
the problem of first winners whose are not usable in real life.
 

That's the purpose of the limit. In a lot of gui programs, actions, and thus
memory allocations, are triggered by events (button/menu clicks, callback
functions for all kind of window updates,...). So there are always a lot of
message related functions on the stack. Since the unit records only
addresses in the main program, all OS / graphics related functions aren't
shown and interpreting the stack can be really challenging. 
IMO, a big improvement would be to unwind the stack instead of checking
every value found on the stack. This would avoid false positives caused by
random data falling in the main address range or by passing function
addresses as a parameter. You could then even drop the check against the
main program address range and include dynamically loaded libraries.
Downside of unwinding a stack is that it becomes difficult when stack frames
are omitted. But for debugging purposes, forcing stack frames is always a
good thing. 

 
I tried to use it with Lazarus (with opening 150 files afterwards) and the
results were bad in terms of the speed, 30 minutes just to start and a
couple hours to work (1.7 Ghz Celeron), obviously something like hash table
is needed. Also showing the number of memory requests for particular
function overall can be also useful, it could add more sense to some
puzzling entries. 
 

A hashtable for MonBlocks and AddrList will help a lot. Keeping AddrList and
FuncNames outside PMMCollectStat would also help for subsequent uses.
The number of requests is something I'm also missing most in the valgrind
massif tool. You get a detailled stack of the memory allocations but you
need to check the code at all levels to check where there are loops and
figure out the count of the loops. 10M allocated by a function executed
10000 times or 10 times changes a lot when trying to find memory "eaters".  

 
As for lazarus results, some entries are still unexplained to me (the first
~300 are in the attachment)

[ 19,832,531 ]  TMAINIDE__DOOPENEDITORFILE
[ 19,801,582 ]  TWIN32WIDGETSET__SETFOREGROUNDWINDOW
the code inside is only Windows.SetForegroundWindow(HWnd), but maybe windows
forces sending message to the tab and this forces the tab (synedit) to make
postponed operations. It's the only explanation I have currently
...
[ 19,749,554 ]  GETWIN32WINDOWINFO
...no explanation
[ 19,686,289 ]  CLEANANDEXPANDFILENAME
...no explanation
[ 14,367,684 ]  FILEGETATTRUTF8
...no explanation

Possibly those were false positives i.e. some numbers on the stack that
falls into usable range, but actually is something else. 
 

Where these results obtained with or withouth the Depth patch? 

 
Max


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20110822/e21347cd/attachment.html>