From: Yusuke ENDOH Date: 2010-03-05T17:58:35+09:00 Subject: [ruby-core:28501] Re: [Feature #905] Add String.new(fixnum) to preallocate large buffer Hi, 2010/3/5 Kornelius Kalnbach : >> Preallocation of String would be immensely useful in large ERB >> templates. > How big would the buffer size have to be for this template? > >

<%= link_to @record.name, @record %>

Yes, it is generally difficult to determine the size. We may be able to estimate it by using domain knowledge in some cases. (e.g., certain page size is empirically known as about 10KB, etc.) But if the expectation is disappointed, it will cause wasteful memory allocation or no speed up. >> So much so, I was looking to patching into rb_str_resize(str, len) >> with a method, to get around related performance issues. Ruby >> Strings already support the difference between the string length and >> the allocated buffer size -- we need to expose it and ensure that >> Strings do not automatically "shrink" the internal String buffers. >> There should probably be a method to explicitly shrink the internal >> buffer, if needed. > This sounds like C to me. Agreed. It is too easy to waste memory. > But I don't say it can't be further optimized in the real world. Agreed. So, we need a benchmark to discuss this. >> For large buffers making this O(1) >> for large strings helps performance and reduces malloc() memory >> fragmentation. > Ropes have been mentioned, they provide constant time concatenation, but > have slower iteration and indexing. They also use more memory. > > Is Array#join optimized for the case where all entries are strings? I think Array#join already does so. Thank you very much for saying almost all I want to say :-) -- Yusuke ENDOH