feat: encodeInto(obj, dest, [options])

[rvagg]

@gozala @alanshaw I was experimenting with this as an encode API - BYO Uint8Array. Unfortunately I can't really measure particularly amazing performance benefits from this, we're already attempting to do a bit of optimisation around allocation already; I think most of the bottlenecks are just in being tied to Uint8Arrays and their perf limitations in the first place. But perhaps you have a use-case that would make this worthwhile?

I'd have to spend a bit more timing cleaning this up and documenting but wanted to see if you had any input on the API and its utility before I bother.

[alanshaw]

I'm interested - is it working? I'd like to try it out. Currenly seeing this flame:

https://bafybeiar654dcjpol4bxqtyfjzyi5n5jleld2ple2qsy4dgpmksavhhikm.ipfs.w3s.link/30826.clinic-flame.html

[rvagg]

Yeah, it works. I'm familiar with similar flame graphs, no matter how much I tinker I can't make it budge much. I have branches here experimenting with flattening the token array so it's not so nested, also tried different methods of writing into the designation Uin8Array because of concerns about set(), none of it makes too much difference. The bottlenecks inherent in Uint8Array handling keep on getting in the way. Happy to take suggestions on new magic to attempt but mostly I keep on coming back here to try new things and walk away disappointed! Like with this attempt. I'd love to claim in the docs that this offers perf benefits but it's not great enough to crow about from my measurements. There may be usage patterns where it does make sense though, where size is known or consistent so you can skip all of the internal allocation dance here and come out winning. Or perhaps you're writing into a very specific piece of a larger buffer and encoding some large chunk where a set() is going to be a problem.