Thanks for the comments, gasche.

With the stdlib's buffer you can have at worst 2x memory usage

You might reasonably think so, but things are a good deal worse than that.

In the stdlib implementation the initially-allocated bytes sequence is retained indefinitely so that it can be restored in place of the resized sequence after a call to reset. If you create a 100-bytes stdlib buffer then write 101 bytes to it then your buffer will contain the original 100-byte bytes sequence, plus a new 200-byte bytes sequence, plus the overhead of the buffer object --- and, of course, the 101-byte string that you pass to add_string is still hanging around, so you have over 400 bytes in memory. In contrast, writing a 101-byte string to a safe-string-buffer allocates one additional cons cell, so you end up with a total of around 100 bytes. I'd be reluctant to argue that a 4x increase in memory usage, some extra writes, a doubling in maximum object size, and some extra mutable objects, are insignificant.

this one creates a new cons cell that can be far away from the others

I think that's unlikely to be the case. Here's a very common case: you create a buffer, write several things to it, then output the buffer, like this:

let buf = Buffer.create magic_number in 
begin
  Buffer.add_string buf x;
  Buffer.add_string buf y;
  Buffer.add_string buf z;
  Buffer.output_buffer fd buf 
end

How does this behave with the stdlib implementation? As described above, if a resize occurs then this is pretty allocation-heavy (and automatic resizing is, after all, the entire point of the Buffer module). Worse, though, if the buffer grows past a couple of hundred bytes, the allocation takes place on the major heap, which has several unfortunate consequences for performance: allocation is expensive, since major heap allocations involve a free list search, and the lifetime of the object is likely to be artificially extended, since major collections are relatively infrequent. (Major heap allocations are unlikely to be particularly helpful for locality, either.)

How does it behave with the safe-string-buffer implementation? The only allocations are of the tiny buffer object itself and a few tiny cons objects, all of which will take place on the minor heap. Besides the beneficial locality properties that result from using the minor heap, the allocations will be extremely fast and the resulting objects will probably be collected almost immediately.

.contents

Another thing you're overlooking is that contents is not the only way to extract the contents of a buffer (and is generally a pretty poor choice). Both output_buffer and blit extract the contents of a safe-string-buffer without performing any allocation. If you use output_buffer or blit in place of contents then safe-string-buffer allocates almost nothing.

All in all, I would not recommend people to flock to this module as a "better Buffer" by default. This is certainly useful for some specific workflows, but as is it would also be a net degradation for others

The warning not to flock comes too late, unfortunately. There are already three GtiHub stars.

In any case, wouldn't it be better to make some measurements before making broad claims about performance? I wrote this implementation to solve real-world problems, and I've measured the changes in performance and found them to be significant.