Implement bufwriter_raw_buffer feature

[tgnottingham]

Tracking issue: #79916

[rust-highfive]

r? @shepmaster

(rust-highfive has picked a reviewer for you, use r? to override)

[tgnottingham]

I'll have a write-up for this in a few.

[tgnottingham]

I've encountered some performance issues with BufWriter that made me think that it might benefit from having a lower-level API. Hoping to hear what others think about it.

The performance issue came up in a change I'm working on that uses BufWriter more heavily in rustc. The change is simple. It changes from writing to a Vec, then writing that Vec to a File, to writing directly to a BufWriter<File>.

The change makes a lot of small writes to BufWriter, which is exactly the use case for which it exists. So one would hope that the performance difference would be rather low. In fact, it's possible using BufWriter could be faster, as it doesn't have to deal with growing and reallocating its buffer, while Vec does. Let's try it out.

Result of switching from baseline to current BufWriter

Very definitely not faster, so I made some trivial changes to BufWriter to improve performance (#79930).

Result of switching from baseline to optimized BufWriter

Obviously, this is enormously better, but it still wasn't satisfying (well, it was very satisfying to improve BufWriter performance, but not satisfying that rustc perf was still bad). So I added the proposed low-level raw buffer API and used that.

Result of switching from baseline to raw buffer API BufWriter

Better...closer...warmer. I can work with it anyway. Here is the raw buffer API vs the optimized BufWriter's existing API.

Result of switching from optimized BufWriter to raw BufWriter API

While the percentage differences seem small, remember that this is the performance difference for the entire compilation of these crates, not the BufWriter performance. An improvement of 4% likely represents many times the improvement in BufWriter performance.

So what is it about the existing API that accounts for the performance difference?

Well, one case in which a difference arises is when you have static knowledge about the input and BufWriter buffer sizes. With this knowledge, you can make repeated writes to the buffer in a way that eliminates bounds checks, errors checks, and all the incidental pessimizations that arise from having to include those checks.

BufWriter likely has no hope of making those optimizations, because it lacks this static knowledge. Even if it had this knowledge, we're generally at the mercy of the optimizer to see through the repeated calls to BufWriter and figure out that it can actually make the optimizations.

This was the use case I had for a raw buffer API, but there may be other cases where a client can do better with it. What do people think about adding this?

@rustbot label T-libs

[shepmaster]

r? @sfackler

[sfackler]

This seems like a strange API to expose from BufWriter, and whatever you're trying to do in rustc may be better served by a custom type.

[tgnottingham]

@sfackler, that's the path I've taken in #80463, and I'm totally fine with it personally.

FWIW, the benefit of being able to use BufWriter instead of a custom type would be not having to reimplement flush and drop (in my case anyway). But that isn't enough for me to want to push for the proposed API.

[sfackler]

Once the ReadBuf type is implemented, I think you could make an interface based off of that which would be a bit cleaner.

[tgnottingham]

Thanks @sfackler. Closing this and the tracking issue.