Why are the Reader and Writer vtables intrusive as well?

[vulpesx]

@paulrt

back to *Writer follow pointer to get *vtable

this was already followed and should still be in cache, it is unlikely the cpu would need to follow it again.

So no, there is still not an extra layer of indirection.

@paulrt

I suppose the whole point with the new Reader/Writer is that this is the cold path which will include a sys call anyway
(I can’t think of a scenario where it wouldn’t be, I think the fixed readers and writers return an error on these paths anyway except the fixed reader flush which is a noop)

whereas for allocator the vtable is always taken, and indirection can matter as it will not always be a sys call (thinking arenas and fixedbufferallocators, this case should still be fast)

Allocating is an example, and no, it does not always take the vtable; It takes advantage of the interfaces built in buffering logic to handle the simple case where there is already available capacity.

Other examples would include the TLS implementations, also the (de)compression implementations.

---

This is not to say there is no merit to your alternative design, it would help alleviate the common foot-gun of copying the interface (and using it after).