[#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:28513] Re: [Feature #905] Add String.new(fixnum) to preallocate large buffer

From: Caleb Clausen <vikkous@...>
Date: 2010-03-05 16:25:21 UTC
List: ruby-core #28513
On 3/5/10, Yusuke ENDOH <mame@tsg.ne.jp> wrote:
> 2010/3/5 Kornelius Kalnbach <murphy@rubychan.de>:
>> How big would the buffer size have to be for this template?
>>
>>  <p><%= link_to @record.name, @record %></p>
>
> 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.

Generally, a given template should expand to about the same size every
time. You can't easily tell ahead of time how big a template will get,
but it's almost never the case that a template is expanded once and
then never again. So, maybe remember what the average expanded size
is, add say a 10% fudge factor, and use that as the initial buffer
size for subsequent expansions. You're not guaranteed that the
expansion will never get bigger than the alloc'd size, but hopefully
that will be rare. It should be a speedup in the average case, and no
slower than the status quo if the guessed size is too small.

The current algorithm wastes up to 49.9% of the allocated string
buffer. On average it might be 25%. This strategy would reduce average
memory wastage to under 10%.

A reasonable _initial_ guess for the expanded size of a template
that's never been expanded before would be the size of the unexpanded
template.

In This Thread