[RFC] Support for huge profile data like TTFP

[kimikage]

I have been changed to not show huge profile data in PR #39 for performance reasons. I've assumed that the main target of ProfileSVG is user code tuning and not the so-called TTFP. However, I believe that the use cases of ProfileSVG are changing as well, considering the migration from Juno to VS Code, and the debut of ProfileVega, a more data-centric approach.

Also, while ProfileSVG have never been able to handle the TTFP just for performance reasons, the combination of measures for issues #41 and #42 (no use of corner rounding) has the "potential" for significant performance improvements. However, these measures would introduce multiple code bases without compatibility for rendering and interactive features.

If you want ProfileSVG to have the same display capabilities as ProfileView, I'll experiment and design for it. On the other hand, if the priority is to tackle a pile of marginal improvements, I'll put the emphasis on code maintainability.

I posted this issue because ProfileView has issues with the large footprint of using GTK and ProfileSVG may have a "potential" advantage. I have some drastic internal design changes for issue #42 in mind and have been unable to decide on the strategy.

Do you have any thoughts?

[kimikage]

Time to first profile view?

The "time" cost of ProfileSVG is a matter of the SVG renderer (e.g. web browser), and the numbers which are obtained by the Julia's profiler do not mean a great deal. However, just FYI, here is the profile of "first profile view". (Edit: Note that ProfileSVG uses the "lazy" printing. Neither rendering nor printing is included in the following profiles.)

Interestingly, the balance (inference, LLVM and mixed) is very similar to the ProfileView's result, even though the actual times are several times different. (cf. https://github.com/JuliaLang/julia/pull/32705#issuecomment-685155916) Of course, much of the operations, including processing in FlameGraphs, is common between ProfileView and ProfileSVG, so it's only natural that the profiles would be somewhat similar, but that alone doesn't explain the difference in the total time.

It's hard to say for sure from the profile sketches alone, but the cost of compilation seems to be determined more by the quantity than by the graph theoretical complexity. Is that wrong?

BTW, this (5,000 frames, 1MB SVG file) is the limit of the "current” ProfileSVG that can be displayed without stress.

[timholy]

It's hard to say for sure from the profile sketches alone, but the cost of compilation seems to be determined more by the quantity than by the graph theoretical complexity. Is that wrong?

Instruction-pointer lookup completely dominates the cost, and that's done by the shared Profile stdlib. You can see that by profiling-the-profiler a second time, after it's all compiled.

I don't have a sufficient understanding of the strengths and weaknesses of SVG to offer much help about this difficult choice. I do know that @staticfloat has some amazing changes coming that should drop

julia> @time using Gtk
Gtk-Message: 04:29:48.563: Failed to load module "canberra-gtk-module"
Gtk-Message: 04:29:48.563: Failed to load module "canberra-gtk-module"
  2.068705 seconds (3.49 M allocations: 227.403 MiB, 1.38% gc time)

to well under a fraction of a second. But that, of course, does not solve the inference and LLVM time issues. I am hopeful that at least over the next year or so we should see progress there too; decreasing latency is a long and multi-fronted battle, but there are now many people fighting that fight.

[kimikage]

Instruction-pointer lookup completely dominates the cost, and that's done by the shared Profile stdlib.

Have you mentioned the cost of the time to "second" profile view? The "post-compilation" costs are not really worth discussing here. As mentioned above, the cost of ProfileSVG is completely dominated by the renderer, not Julia. :smile:

[kimikage]

Although ProfileSVG and ProfileVega both target the same platform, I don't think they are very competitive in terms of architecture. Vega is data-centric, and the flamegraph is only one aspect of the data. On the other hand, ProfileSVG has the style of flamegraph first, and then the data is embedded into it.

ProfileSVG and ProfileView have different target platforms, but they also differ in the scale of the graphs they can handle. If the graph size limitation in ProfileSVG is affecting the user's choice of tools, I would prefer to provide a viewer which works on a web interface. It doesn't really matter whether GTK is fast or slow in this regard. (Speed is justice, of course!) I'm not sure that is really necessary now that VS code's profiler integration is available.

[kimikage]

Inference profiling is a (new) application which can generate huge graphs. I don't have any immediate concrete plans, but being able to handle huge profile data is definitely one of the goals of this package. :smile: