Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Support for huge profile data like TTFP #44

Closed
kimikage opened this issue Sep 2, 2020 · 5 comments
Closed

[RFC] Support for huge profile data like TTFP #44

kimikage opened this issue Sep 2, 2020 · 5 comments

Comments

@kimikage
Copy link
Owner

kimikage commented Sep 2, 2020

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
Copy link
Owner Author

kimikage commented Sep 2, 2020

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.)

ttfpv_svg

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. JuliaLang/julia#32705 (comment))
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
Copy link
Collaborator

timholy commented Sep 2, 2020

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
Copy link
Owner Author

kimikage commented Sep 2, 2020

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. 😄

@kimikage
Copy link
Owner Author

kimikage commented Sep 2, 2020

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
Copy link
Owner Author

kimikage commented Sep 7, 2021

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. 😄

@kimikage kimikage closed this as completed Sep 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants