Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report for Bug 31097 on
Developer Community if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
There's a great opportunity to add value to the Xamarin Studio product by bringing back into the IDE the timing and memory statistics that the profiler has assembled.
If each line of my code could be annotated (a la Visual Studio's references annotations perhaps) with memory and timing data, number of iterations, etc, this would add massive value to the data that the profiler produces.
The current version of the profiler (0.16) requires me to navigate around its own interface, often without the benefit of a search / filter tool, in order to find out information about execution timings and memory usage in my code. This interface is unfamiliar and slightly strange - a foreign language to most developers, who aren't usually profiling experts in their own right.
However, all developers are intimately familiar with their IDE. So it makes much good sense to me to allow the IDE to pick up the profiler's latest report (or even a history of reports) and overlay that information on the code. Xcode is beginning to do this in its testing mode, but there's no reason why this useful and helpful data should be restricted to just tests.
I have many ideas about how to present this information visually. Please contact me when you're able to discuss them.
This is a nice feature indeed, but it will take a bit to get it implemented, as we have more important things to fix right now (performance and data correctness), but will do as soon as time permits
I would be happy to accept data as it is currently generated by the profiler (v0.16) because this feature is "after the fact" and doesn't require the profiler to display its statistics and calculations in real time. Although it would be really nice to have this data available while you're single-stepping the debugger! :)
We are starting work on this, but it won't be ready until 15.2, so moving milestone