Coincidentally, this also fixes #95 since the unbounded queue has been removed.

This is excellent. I'll need some time to refamiliarize myself with this code, fetch your branch, compile it, run the tests, etc. But - thanks in advance for the contribution.

It might also be possible to save on the allocation per message by avoiding the Iterator interface and instead providing a function like
next_preallocated<'a>(&muf self, buf: &'a mut Vec) -> Option<&'a [u8]>,
on the ByteConsumer Trait.
and then changing the main loop from for... to while let ...

I am not sure about the performance improvements there though

EDIT:
real 1m14.688s
user 1m13.367s
sys 0m1.040s

reusing the message buffer seems to account for ~5s in my use case. (a further improvement of about 6%).

Since this would requires some changes in the interface to the stream-delimit subcrate, I'd open a new pullrequest for discussion if you are open to the idea.

Since this would requires some changes in the interface to the stream-delimit subcrate, I'd open a new pullrequest for discussion if you are open to the idea.

I'm open.

I have time to clone and test this today.

Can you compare your code against this previous (merged) PR: #81

That PR added the call to "spawn" in the first place, and now I see you're removing that part.

Can you compare your code against this previous (merged) PR: #81

I am not sure what you mean by compare, as the first measurement (and flamegraph) is already done on master, which includes the threaded code

Before #81 was merged, each message was also deserialized to a temporary serde_value::Value object, suffering from the same allocations and double traversal it now does.

Regarding the removal of the threads, its still faster because:
The main reason for the speedup in this case is the fact that we can avoid constructing an itermediate value, and so only have to traverse each message once.
This means that we cant run decoding and encoding in separarate threads though.

In theory it might be possible to parallelize on a message level (transcoding multiple messages simultaneously)
I cant think of an easy way to do it without giving up ordering guarantees in the output though.

Just wanted to make sure we're not walking back any desired behavior. Anyway it looks OK on my end, performance improved.

Thanks. I could either cut a release or wait for the next idea you had.