[eatfish]

Only played with it a bit so far but it seems to me that the call and flame charts are now missing any timing information. Unless I've overlooked it you can't actually see how long a function takes to execute - defeats the purpose of instrumented profiling surely!

[kllrnohj]

Instrumented trace capture modifies the execution profile too much for timing information to be useful, and then sampling profiling which doesn't modify the execution profile doesn't have timing by its nature.

So if you were using the timing data previously you were basically just looking at random numbers that would send you on wild chases into things that weren't real. The new one fixes that by not showing bogus data :)

[eatfish]

That's not a fair comment and you know it.

Yes, instrumentation adds overhead. The absolute numbers cannot be used to determine peak performance but that's never the intention when profiling code.

Instrumentation rarely modifies the execution profile to the point that the numbers are 'worthless' or 'random'. My rule of thumb is that self times near the leaves of the callgraph are more accurate than self times further up the graph but having some indication of timing is important.

Furthermore with something like the call chart in AS3 you are often looking for outliers that you can't see when looking at an aggregated view of the profile. A function that has an average of 1000us might be running alternately at 500us and 1500us and you want to see that. It may indicate an unknown performance bottleneck, maybe a call to OpenGL is causing a GPU sync for some reason. It's rare that the instrumentation overhead would dominate major effects like that. Having a number available is important for this as you may be comparing invocations/looking at different parts of the graph at different zoom levels etc. Having a number available is the only solution.

Furthermore, where do you think the instrumented profiler is getting numbers from in the aggregated views? Answer: exactly the same place that the callchart gets it's numbers from. In essence you are saying all instrumented profilers are inaccurate and reporting bogus numbers, demonstrably untrue.

[kllrnohj]

> Instrumentation rarely modifies the execution profile to the point that the numbers are 'worthless' or 'random'. My rule of thumb is that self times near the leaves of the callgraph are more accurate than self times further up the graph but having some indication of timing is important.

I was only talking about the instrumentation system on Android, not the one anywhere else. It forced ART to fall back to interpreted mode, so no JIT at all, which massively balloons the cost of certain things like single-line getters or JNI calls. It was actually useless as a performance tool of any kind, which is why the recommendation for years has been to ignore the numbers it produced. It's great at answering questions about what a given function ends up doing, but that's it.

If you want low-overhead timelines with duration numbers that actually have meaning that's the job of systrace ( https://developer.android.com/studio/command-line/systrace.h... ).