Open mkustermann opened 3 months ago
CC @bkonyi
Another thing is that I believe loading CPU profiles can freeze the UI for a while - most likely due to all this work happening synchronously without any yields to the event loop. I have observed 80 MB of json to be loaded for cpu profile, which may result in quite a bit more of in-memory json (consumed by maps, lists, etc - which aren't as compact as in the encoded form) - possibly 100s of MBs it's churning through synchronously several times.
Could we make this function async? Then we can batch the processing and avoid janking frames...
Friendly ping. @kenzieschmoll @bkonyi Are there plans on improving this in the short/mid term?
@mkustermann thanks for the performance analysis. It sounds like all of your recommendations would be great improvements. In practice, this isn't something we have the cycles to work on in the short term, but are more than happy to accept & review contributions if you'd like to take a stab at any of these.
After having taken a look at the cpu profiling code in DevTools, we found:
Stream</* String | List<int> */>
from the websocket and then json decodes strings => It would be more efficient to avoid going from utf-8 to string and then to json and instead directly from utf8->json => This would probably require some refactoring in various packages, so maybe not easily doable?package:vm_service layer
package:vm_service
layer (e.g.vm_service.CpuSamples
,vm_service.CpuSample
)_CpuProfileTimelineTree
tree structure => Uses expandos (!!) to map service objects back to tree nodes_CpuProfileTimelineTree
-> JSON "traceObject" (very expensive operation!)CpuProfileData.fromJson
which builds json maps with strings andCpuStackFrame
as valuesIt seems there's too many conversions from one data structure to another and the representations used for encoding this profiling information doesn't seem very efficient either.