<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>
<META content="MSHTML 6.00.6000.16544" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2></FONT><FONT face=Arial color=#0000ff
size=2></FONT><FONT face=Arial color=#0000ff size=2></FONT><BR> </DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"><FONT
face=Arial color=#0000ff size=2></FONT>
<DIV><FONT face=Arial color=#0000ff size=2></FONT><FONT face=Arial
color=#0000ff size=2></FONT><FONT face=Arial color=#0000ff size=2></FONT><FONT
face=Arial color=#0000ff size=2></FONT><BR>These are useful additions, thanks.
I suppose the limit automatically solves the problem of first winners whose
are not usable in real life.<BR><SPAN class=953154608-22082011><FONT
face=Arial color=#0000ff size=2> </FONT></SPAN></DIV></BLOCKQUOTE>
<DIV><SPAN class=953154608-22082011><FONT face=Arial color=#0000ff size=2>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. </FONT></SPAN></DIV>
<DIV><SPAN class=953154608-22082011><FONT face=Arial color=#0000ff size=2>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.
</FONT></SPAN></DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV><SPAN class=953154608-22082011> </SPAN><BR>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. <BR><SPAN
class=953154608-22082011><FONT face=Arial color=#0000ff
size=2> </FONT></SPAN></DIV></BLOCKQUOTE>
<DIV><SPAN class=953154608-22082011><FONT face=Arial color=#0000ff size=2>A
hashtable for MonBlocks and AddrList will help a lot. Keeping AddrList and
FuncNames outside PMMCollectStat would also help for subsequent
uses.</FONT></SPAN></DIV>
<DIV><SPAN class=953154608-22082011><FONT face=Arial color=#0000ff size=2>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". </FONT></SPAN></DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV><SPAN class=953154608-22082011> </SPAN><BR>As for lazarus results,
some entries are still unexplained to me (the first ~300 are in the
attachment)<BR><BR>[ 19,832,531 ] TMAINIDE__DOOPENEDITORFILE<BR>[
19,801,582 ] TWIN32WIDGETSET__SETFOREGROUNDWINDOW<BR>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<BR>...<BR>[ 19,749,554
] GETWIN32WINDOWINFO<BR>...no explanation<BR>[ 19,686,289 ]
CLEANANDEXPANDFILENAME<BR>...no explanation<BR>[ 14,367,684 ]
FILEGETATTRUTF8<BR>...no explanation<BR><BR>Possibly those were false
positives i.e. some numbers on the stack that falls into usable range, but
actually is something else. <BR><SPAN class=953154608-22082011><FONT
face=Arial color=#0000ff size=2> </FONT></SPAN></DIV></BLOCKQUOTE>
<DIV><SPAN class=953154608-22082011><FONT face=Arial color=#0000ff size=2>Where
these results obtained with or withouth the Depth patch?
</FONT></SPAN></DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV><SPAN
class=953154608-22082011> </SPAN><BR>Max<BR></DIV></BLOCKQUOTE></BODY></HTML>