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 _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
