By backing RESPError fields in a class.
This way it isn't taking up storage in
each and every RESPValue.
25 is still > 24 though :-)
(thanks to @weissi for the suggestion)
... this may be a no-op optimization,
but well.
It is actually trigger to do the right thing here.
In this version we flush the `values` array, which
transfers ownership of the array buffer to the
RESPValue.
But that buffer is never going to be modified, so
it would be nice to keep it alive. But if we do
keep it alive, we also keep the RESPValues alive,
which may point to full ByteBuffer's, which is
not desirable.
Whatever you do in Swift, you loose ;-)
Disadvantage is that we cannot reuse the
Contiguous value array for the top-level
item.
(we could try to cache the struct in an
ivar w/ a few hops).
Another option would be to use a fixed
size array or even a buffer-bptr to avoid
the range checks.
Instead of being embedded in the RedisChannel,
move the parser out, into an own struct.
This way we may be able to avoid NIO channel
pipeline overhead (NIOAny wrapping).
Helge Heß