The type erased reader changes massively impact zig's IO performance for buffered readers, fixed buffer streams, etc.

[tomc1998]

I'm using 0.13.0 stable, although from browsing the source on master the issue is still present.

The type erased reader changes (#17344) need to be reverted: there is currently no way to efficiently do IO with zig's stdlib, IO API feels like a performance trap.

Prior to the type-erased reader changes, if I need to write a function that parses a file, I take a reader by anytype and implement the function on that. At compile time I could switch out a BufferedReader or FixedBufferStream reader and still get good performance.

Now however, the performance is significantly worse after 0.13.0. I've got a function which loads java .class files and parses them. I'm seeing a 2x performance loss comparing the current type-erased FixedBufferStream and a custom Reader implementation without any dynamic calls. This is with many complex allocations to store the results of the parse: the reader performance issue is worse if I'm doing something simpler with fewer allocations. You can also see these results in other issues that have been opened: #21566, #17985.

This is because the type erased reader changes prevents anything from being inlined: so when profiling an IO function I can see a lot of samples in readByte, for example. I would expect any calls to readByte on a FixedBufferStream to be inlined and optimized to a couple instructions, so any reader functions being present in the profile is a bad sign. AFAIK prior to 0.13.0 this inlining happened; I never saw these functions in the profile, and performance was much better.

In 0.13.0, any time I use the zig stdlib IO reader/writer APIs I regret it, which is unfortunate.