You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When flamegraph is generated programmatically, converting to string and back makes code less type safe (e.g. strings may be not escaped correctly).
But eventually API could be evolved to provide more detailed information. In particular, in out setup we measure both number of bytes and number of chunks.
Such API can be extended to provide labels to nodes. So it would still take value_excluding_children to compute width, but Tree could have additional node like extra: String which would be shown when clicked, and we could place number of chunks or any other text info into that extra field.
The text was updated successfully, but these errors were encountered:
It's a good idea! This is basically a duplicate of #164, which in turn really comes down to #30. It's something I would love for us to add, but that I also don't have the spare cycles to implement myself at the moment 😅 If you want to take it on though, please do!
Current API only accepts strings.
Would be helpful if it could accept something like:
When flamegraph is generated programmatically, converting to string and back makes code less type safe (e.g. strings may be not escaped correctly).
But eventually API could be evolved to provide more detailed information. In particular, in out setup we measure both number of bytes and number of chunks.
Such API can be extended to provide labels to nodes. So it would still take
value_excluding_children
to compute width, butTree
could have additional node likeextra: String
which would be shown when clicked, and we could place number of chunks or any other text info into thatextra
field.The text was updated successfully, but these errors were encountered: