Share BytesStarts across frames in flamegraph

[jonhoo]

While #37 got us pretty far, there is still one source of allocation in the main flamegraph loop: the attributes on BytesStart. Specifically, when you add attributes to a BytesStart, it allocates a Vec to hold the underlying bytes if it doesn't already have a Vec. That's unfortunate since we create a new BytesStart for every g. If we instead created a single BytesStart that we re-used somehow (by resetting all the attributes), that'd be way more efficient. Sadly, that's not yet supported, but I've filed tafia/quick-xml#148 which would enable us to do that!

[meven]

FYI, I have opened a PR in quick-xml repo tafia/quick-xml#149 to fix tafia/quick-xml#148

[jonhoo]

Now that tafia/quick-xml#149 has landed, this should be easy-peasy! :D

[meven]

Now that tafia/quick-xml#149 has landed, this should be easy-peasy! :D

Well we just need to wait for a quick-xml release now.

[jonhoo]

@meven I would start working with quick-xml as a git dependency, and then we can just hold off on releasing until a new release of quick-xml is made :)

[meven]

Having a look unfortunately Event::Start consumes the BytesStart.
We will need a clone() unfortunately.

[jonhoo]

Ah, that's unfortunate. The clone will at least mean that we're unlikely to do multiple memory allocations though. @tafia any idea how we may be able to do this without allocation, given that Event;;Start consumes BytesStart (as opposed to taking a &BytesStart)?

[tafia]

Event is the primary enum returned in quick_xml. I think it wouldn't make sense for it not to own its content (in particular when reading the xml).

On the other hand, Writer::write_event takes a AsRef<Event> but you're using write_event(event).

So if instead you decide to use write_event(&event), you could then get back the event (if let Event(start) = event) and do whatever you need.

I haven't tried it on your code but it should work.

[jonhoo]

We should also do this for the rect and a elements, since they're also in the main loop. /cc @meven

[jonhoo]

I would probably work on this on top of #32 rather than current master since it's about to be merged, and moves a lot of code around.

[meven]

I would probably work on this on top of #32 rather than current master since it's about to be merged, and moves a lot of code around.

Good suggestion, I can do that.