[ruby-core:73532] [Ruby trunk - Feature #12024] Add String.buffer, for creating strings with large capacities

Issue #12024 has been updated by Yusuke Endoh.


I'm unsure if this pre-allocation is really effective since recent "realloc" implementations take just O(1).  What operating system are you using?

In #905, pre-allocation was actually helpful in JRuby because JVM did not provide such a good "realloc" feature.  But the speed up was not confirmed in Linux.  So the issue was, "should MRI provide the feature for script compatibility, even if it is meaningless in Linux?"

However, even if the computational order is O(1), it may have a large constant term.  I'm not against the proposal if a real-world quantitative evaluation shows use case where it is actually effective.

-- 
Yusuke Endoh <[e-mail]>

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

* 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:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>