This one came up on IRC today.

I'm not opposed to this, but currently we implement it the same way MRI does (nearly line-for-line). I'd like to know if there's a reason it's implemented that way, since there are even specs and tests that check for the separate writes.

Oh, I did think of one explanation: zero-allocation puts. If you have to stick the \n on a buffer to do it as one write, you'll probably have to allocate a new buffer.

Our puts logic currently isn't zero-alloc, but it could be.

@headius I think this has languished because of the fear of the unknown. In most of our optimizations of reducing dyncalls we cannot observe a change in behavior. The behavior @cheald fixes as was pointed out in original report is what MRI does as well (weird interleaved output). So even if this is faster it will change behaviorally. If we think no one will really want this behavior (and that is likely true), then we need to consider test suites mocking to make sure there are two write() calls. The only way of getting around that would be to check if this is being called from builtin version of the method. Seems like this is a ways beneath that point. We could pass that and then remove the cost?

The cost of the two dynamic calls should be close to negligible at this point, since we added call-site caching. The only real benefit is performing the write in one go.

An alternative would be to lock the IO around the puts logic, but that would also need to check if write had been replaced (since there's no IO-locking semantics in MRI puts).

I don't think we'll do this. If you are using an IO across threads, it guarantees only that its internal logic and buffering will be thread-safe, not that any given call will be atomic (and indeed, even write calls might get turned into multiple native calls). If you want atomicity of groups of writes, including implicit cases like puts, you can introduced a lock or use the JRuby::Synchronized module.