I stumbled upon
opentracing.io some time ago and while it is primarily designed to trace distributed services you can also use it to trace a single process obviously.
GWT compiler can produce speedtracer logs but you can not easily visualize them because the Chrome plugin does not work anymore. So I thought I give it a try and as a POC I have changed the implementation of the current speedtracer event API inside GWT compiler to record timings using
opentracing.io API (just wanted to avoid updating lots of call sites). As a result I can now start SuperDevMode using some JVM system parameters like
-Dgwt.opentracing.tracerImpl=com.example.tracing.zipkin.ZipkinOpenTracingTracer (without it a NoopTracer will be used)
-Dzipkin.serviceName=SuperDevMode
and launch a Zipkin server
docker run -d -p 9411:9411 openzipkin/zipkin
(or any other
opentracing.io compatible server that stores and visualizes the timing information. You would need to implement a different Tracer then)
Now every time SDM compiles, all speedtracer events are converted into
opentracing.io spans and you get some visualization like:
There are some rough edges to be solved, like a single recompile results in multiple traces not yet connected to each other, but I though I'll just share this quick POC with you.
Given the future of GWT 2.x I am not sure if it is worth investing more time in it but at least it shows that a relatively easy migration would be possible to some newer (standard) tools to visualize compiler timings again. So if we want to make speedtracer logs useable again this might be an option.
-- J.