[#28687] [Bug #2973] rb_bug - Segmentation fault - error.c:213 — rudolf gavlas <redmine@...>

Bug #2973: rb_bug - Segmentation fault - error.c:213

10 messages 2010/03/16

[#28735] [Bug #2982] Ruby tries to link with both openssl and readline — Lucas Nussbaum <redmine@...>

Bug #2982: Ruby tries to link with both openssl and readline

16 messages 2010/03/18

[#28736] [Bug #2983] Ruby (GPLv2 only) tries to link to with readline (now GPLv3) — Lucas Nussbaum <redmine@...>

Bug #2983: Ruby (GPLv2 only) tries to link to with readline (now GPLv3)

10 messages 2010/03/18

[#28907] [Bug #3000] Open SSL Segfaults — Christian Höltje <redmine@...>

Bug #3000: Open SSL Segfaults

19 messages 2010/03/23

[#28924] [Bug #3005] Ruby core dump - [BUG] rb_sys_fail() - errno == 0 — Sebastian YEPES <redmine@...>

Bug #3005: Ruby core dump - [BUG] rb_sys_fail() - errno == 0

10 messages 2010/03/24

[#28954] [Feature #3010] slow require gems in ruby 1.9.1 — Miao Jiang <redmine@...>

Feature #3010: slow require gems in ruby 1.9.1

15 messages 2010/03/24

[#29179] [Bug #3071] Convert rubygems and rdoc to use psych — Aaron Patterson <redmine@...>

Bug #3071: Convert rubygems and rdoc to use psych

10 messages 2010/03/31

[ruby-core:28493] Re: [Feature #905] Add String.new(fixnum) to preallocate large buffer

From: Kornelius Kalnbach <murphy@...>
Date: 2010-03-05 02:58:25 UTC
List: ruby-core #28493
On 05.03.10 01:13, Kurt Stephens wrote:
> Preallocation of String would be immensely useful in large ERB
> templates.
How big would the buffer size have to be for this template?

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

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

> From what I can tell string growth is roughly O(log2 N) because of
> the power-of-2 buffer resizing.
You probably mean O(N * log2 N). But even in the worst case (smallest
possible steps, string data must be relocated for each buffer
extension), it's still just O(N) where N is the length of the final
string. Example:

s = ''
s << '1' # allocate 1 byte, relocate 0 bytes, write 1 byte
s << '2' # allocate 2 bytes, relocate 1 byte, write 1 byte
s << '3' # allocate 4 bytes, relocate 2 bytes, write 1 byte
s << '4' # write 1 byte (buffer is long enough)
s << '5' # allocate 8 bytes, relocate 4 bytes, write 1 byte
...

So it's exactly n bytes for the writes, and O(n) bytes must be relocated
in total (about 2*n since sum[i=0..k] 2^i < 2^(k+1)). Allocation itself
is O(1) for each step.

But I don't say it can't be further optimized in the real world.

> 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? As in:

  if array.all? { |obj| obj.is_a? String }
    buffer_size = array.map { |str| str.size }.sum
  else
    buffer_size = whatever
  end
  result = allocate(buffer_size)
  array.each { |str| result << str }

We could have rope-like performance for concatenation then by using
Arrays, and #join them in linear time to get the final result. Wouldn't
change the complexity, but is probably faster.

[murphy]

In This Thread