In my experience the times reported by @profview were wildly inaccurate and mostly useless; in general, they are proportional to the sample count also shown in the new UI, so there shouldnât be less info here (just less pretending to give you accurate timings).
I strongly prefer the old way. Why would you just remove a feature? It would also display the self and total times above each function. I know it wasnât super accurate but it was extremely useful to me.
Not only you. The old way is a kind of âmatlabâ style(what i hateâŚ), but very easy to see although as pfitzseb said itâs inaccurate. I guess the inaccuracy is most big problem, and we should lean that âflame graphâ or anythingâŚ
I did a little research and hereâs what I found. The âold wayâ was just generating a .cpuprofile file and opening it with vscodeâs built-in .cpuprofile viewer, vscode-js-profile-visualizer, originally designed for js profiling. This is still possible to do manually by using ChromeProfileFormat.jl to generate a .cpuprofile file.
The ânew wayâ is to use a Julia-specific package to display profile results: ProfileCanvas.jl. Itâs probably a good idea in the long run to stop relying on vscode-js-profile-visualizer, and the new package also gives us control over how profile results are displayed. Unfortunately ProfileCanvas.jl is not being actively developed, so weâre stuck with the current format until somebody decides to take it on.
@pfitzseb might have something to say about ProfileCanvas not being âactively developedâ I seem to recall quite a bit of activity a few months back
Youâre right, sorry. @pfitzeb has indeed been doing great work on this package, indeed heâs carried it solo up till now. Itâs a good package to have, and it looks great! But he is after all just one person who by his own admission doesnât have time to work on this feature. There is an issue open for it, though, and I think it would great for new contributors to help share the load. Iâm currently trying to finish my degree so time is at a bit of a premium, but Iâll lend a hand if I can find the time.
I seem to recall there being some mechanism for tagging issues as good entry points for new contributors. Would that be appropriate/possible in this case?
As always, things like these are a matter of prioritization â we havenât had many people telling us theyâre missing the old UI, for example (roughly four, including this thread, if I remember correctly). Also note that the switch to our own UI did fix a actual issues with the previous solution, I didnât just decide to implement that for fun