Replace SpeedTracer with some other event/metric recording API

[niloc132]

GWT 2.12 will deprecate SpeedTracer - the application that can ingest the generated output no longer seems to be usable. We should plan to replace it with something else that can be consumed more easily by developers who don't already know how the compiler works.

The Flight Recorder APIs introduced in Java 11 might serve as a good choice here, allowing projects to generate details about consumed time/resources in their compilation for review.

[jnehlmeier]

I once did a PoC using OpenTracing (now OpenTelemetry) which was relatively easy to implement. If I remember correctly I only had to implement the speedtracer logger differently and reused all the events already published in compiler code.

https://groups.google.com/g/google-web-toolkit-contributors/c/n2ZzcStB0BI/m/y6lPDC-FBAAJ

It was nice to see the individual steps visualized and you could add logs to each step if you want to. But the visualizer had some trouble displaying everything smoothly because the compiler produced quite a bit data and I had the feeling that either the published start/stop events were not up-to-date or the compiler used some threads here and there which I didn't handle in the PoC. So this would need some work.

This was prior JFR APIs so JFR is probably a better fit now, possibly with a flame graph plugin if it exists.

[niloc132]

That sounds like a great idea too - I would slightly lean towards replacing the speedtracer api with something else entirely:

• so it is easier to add new features as needed/desired without an extra indirection step
• so individual callsites can use the underlying api to advertise specific details they know about directly

On the other hand, keeping the existing API would make it possible to have "multiple backends", though I'm really not sure what value that would bring.

I'd be curious if browsers (and the opentelemetry viewers) have gotten better fast enough that your prototype might be fast enough to work today?

Is your code available anywhere to take a look at?

[jnehlmeier]

so individual callsites can use the underlying api to advertise specific details they know about directly

OpenTelemetry allows attributes (key/value map) on spans and span events to publish interesting information available to the call site. It also allows publishing metrics.

I'd be curious if browsers (and the opentelemetry viewers) have gotten better fast enough that your prototype might be fast enough to work today?

Maybe. It was a very simple PoC and all speedtracer events ended up as OpenTracing spans. There were a lot of them with very small duration of just some micro seconds. I feel like those are more like "notification events" that something happend and took x-time and then should be stored as a span event, similar to storing logs on a span.

So I assume that the output can be greatly improved which would also improve performance of viewers.

Is your code available anywhere to take a look at?

I guess it is gone. Maybe in some old local backup lingering around but it is not pushed anywhere. I think it was a couple of hours of work implementing some start/end methods and commenting everything that had become red / unused.

--

But in general OpenTelemetry solves a higher level use-case than JFR as you would not do method profiling using OpenTelemetry. With OpenTelemetry you would capture broader compiler phases spanning multiple methods (= span) and then attach meaningful events/logs to these spans. So similar how you would do it using microservices but within a single process.

If we want to go very detailed then JFR is probably a better fit.