Issue #12024 has been updated by Yusuke Endoh.


Thank you for your benchmark.  I tried it and confirmed the speed up in Linux.  Now I have no strong objection against your proposal.

realloc takes O(1) if the size is much larger than page size (4096B in Linux), but the benchmark starts from a much shorter string, which requires memcpy.  I thought this constant term was not so big, but seems it is.  Kosaki-san may have an opinion about this.

I have no strong objection, but still I have a question.  I guess that creating a large string by concatenating many short strings is natural use case in Ruby.  However, are there so much cases where we can predict the final length of a generated string before starting creating it?

I think the most typical application that can benefit from this feature is a template engine, but it is difficult to tell the length of a string being generated before it is actually generated.

-- 
Yusuke Endoh <mame / ruby-lang.org>

----------------------------------------
Feature #12024: Add String.buffer, for creating strings with large capacities
https://bugs.ruby-lang.org/issues/12024#change-56799

* Author: Jeremy Evans
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
If you know you are going to need to create a large string,
it's better to create it with a large capacity.  Otherwise,
ruby will need to continuously resize the string as it grows.
For example, if you will be producing a string that is
100000 bytes, String.buffer(100000) will avoid 10 separate
resizes compared to using String.new.

Performance-wise, String.new is 1.33x slower than
String.buffer(100000) if appending in 1000 byte chunks,
and 1.64x slower than String.buffer(1000) if appending
in 100 byte chunks.

To make sure this works correctly with String subclasses,
a static rb_str_buf_new_with_class function is added, which
both String.buffer and rb_str_buf_new now call.


---Files--------------------------------
0001-Add-String.buffer-for-creating-strings-with-large-ca.patch (3.53 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>