Performance improvements to CPU profile code

[mkustermann]

After having taken a look at the cpu profiling code in DevTools, we found:

• It unnecessarily encodes json maps and decodes them again: devtools/pull/7916
• It gets 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?
• Way too many conversions
  • Bytes->String in websocket layer
  • String->JSON in package:vm_service layer
  • JSON -> service objects in package:vm_service layer (e.g. vm_service.CpuSamples, vm_service.CpuSample)
  • service objects -> _CpuProfileTimelineTree tree structure
    => Uses expandos (!!) to map service objects back to tree nodes
  • _CpuProfileTimelineTree -> JSON "traceObject" (very expensive operation!)
  • Going from JSON "traceObject" back to normal objects in CpuProfileData.fromJson which builds json maps with strings and CpuStackFrame as values

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

[kenzieschmoll]

CC @bkonyi

[mkustermann]

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.

[kevmoo]

Could we make this function async? Then we can batch the processing and avoid janking frames...