[Mono-dev] Profiler todo list

[Massimiliano Mantione]

On Mon, 2008-07-28 at 11:23 +0100, Marek Safar wrote:
> Would it be possible to show detailed string allocations? What I usually 
> get is something like 100000 byte of string allocations but it would be 
> helpful to see let say top N strings.

Well, possible, yes, like everything :-)

The profiler currently does not write object values in the log file
(well, the heap snapshot section gets close to that, but only for
references...).

For sure it would be possible to extend it to include the contents of
string objects.

But... let's put it this way: I am not the one that will raise the
priority of this feature.

It is only useful if you have to deal with excess allocations of
strings, while for all other types you would still have to resort to:
- caller attribution of the allocation,
- collection summary data (currently implemented but broken, I should
commit the fix today), and
- maybe (when done) the "user timestamped annotations" so that you can
mark particular "regions" in the timeline your application execution
(the ones I was referring to in my previous message).

Another thing I had in mind was to allow the user to insert those
timestamped markers programmatically (and maybe label them with strings,
too).
I mean, export to the application something like
"Mono.Profiler.Marker.Create (string message)"
that would put a timestamped mark on the file.
I guess this would also help in pinpointing what part of the application
is responsible for allocations (or also execution time).

Another improvement would be having a GUI that lets you explore the
timeline: when we activate the "c" option the file actually contains a
*full* timestamped trace of all method enter and exit, navigating that
and filtering things based on the timeline and-or method names (and
include callees) would be very nice.
The data is already there, it's the interface that's missing.

All the above would improve the profiler effectiveness when working on
allocations of every type, and not just string.
So, it is true that string is a very common type where allocations can
be a big issue, but I'm not sure that putting all string values in the
log file is the first thing we should try to help pinpointing the
problems.

That said, if there's popular demand for it... ;-)

Ciao,
  Massi