[fpc-pascal] Is such memory statisticspossible?

[Max Vlasov]

On Mon, Aug 22, 2011 at 1:30 PM, Ludo Brands <ludo.brands at free.fr> wrote:

> **
>
> 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.
>

Interesting suggestion, can you point to some code maybe in the lazarus that
does a similar job. Does GetLineInfo inside do something like this?


>
> 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.
>
>
> Keeping AddrList and FuncNames outside PMMCollectStat would also help for
> subsequent uses.
>

You're right about FuncNames, I checked for GetLineInfo speed, it's about
100 per second on my machine. The speed is good for lazarus "call stack"
window, but for resolving dozens of addresses the caching of the results
might become a necessity.


> As for lazarus results, some entries are still unexplained to me (the first
> ~300 are in the attachment)
> ...
> 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?
>
>
It was before and looking at how much cpu time spent, I will be probably
ready for the next measurement only after the hashing is implemented :). In
you question I see a guess, that the fewer the depth, the less likely false
positives get into view, right?

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