Issue #12024 has been updated by Jeremy Evans.


Template engines would be the main use case for this.  Note that you don't need to know the exact length of the string.  If you know your average generated string is 8k, you can use a 8k buffer by default.  If the string generated is only 2k, I'm guessing it still increases performance, and doesn't really cost you any memory in the long term as such strings are garbage collected quickly.  If the page generated is 100k, starting with an 8k buffer will still increase performance as it saves you many reallocs.

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

* 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>