Issue #905 has been updated by mame (Yusuke Endoh).


Hello headius,

headius (Charles Nutter) wrote:
> Trying to wake this beast up...
> 
> mame: I don't think we can say it would not help MRI without testing an implementation, can we? I misunderstood realloc in my comment from two years (!!!) ago According to realloc docs:

Linux's realloc(3) man-page does NOT say that.

http://www.kernel.org/doc/man-pages/online/pages/man3/malloc.3.html

Perhaps you saw os x's realloc?
I wonder this issue is valid on os x.
Anyone can conduct a quantitative investigation?


headius (Charles Nutter) wrote:
> I do not believe for a moment that realloc or mremap can in all cases perform the operation in O(1) time, and the docs seem to agree with me...first based on the doc above for realloc, and then for this doc on mremap:

Looks irrelevant.  I guess realloc(3) just uses mremap with MREMAP_MAYMOVE
internally.

-- 
Yusuke Endoh <mame / tsg.ne.jp>
----------------------------------------
Feature #905: Add String.new(fixnum) to preallocate large buffer
https://bugs.ruby-lang.org/issues/905#change-31744

Author: headius (Charles Nutter)
Status: Feedback
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: 
Target version: 2.0.0


=begin
 Because Strings are used in ruby as arbitrary byte buffers, and because the cost of growing a String increases as it gets larger (especially when it starts small), String.new should support a form that takes a fixnum and ensures the backing store will have at least that much room. This is analogous to Array.new(fixnum) which does the same thing.
 
 The simple implementation of this would just add a Fixnum check to the String.new method, and the result would be an empty string with that size buffer. This would allow heavy string-appending algorithms and libraries (like ERb) to avoid doing so many memory copies while they run.
=end



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