On Thu, 31 May 2007 23:09:54 -0700 Mark Glines <[EMAIL PROTECTED]> wrote: > Might be worth it to prereserve 8 bytes or so, to avoid having to > realloc as often, if this will be called a lot. Currently it just > reallocs the minimum necessary to fit the existing string, the new > character and a null terminator.
There is a performance impact from the additional check, but I don't think the above optimization is necessary... or its possible Parrot_reallocate_string() already reserves extra room internally. Either way, I don't see enough of a performance hit from the patch to be too worried about this. I tried "prove t/op t/library" with different scenarios, to try to measure the performance impact. Here are the setups and the results: Configure.pl with no args, and no patches applied All tests successful, 2 tests and 172 subtests skipped. Files=56, Tests=2488, 73 wallclock secs (51.64 cusr + 11.49 csys = 63.13 CPU) Configure.pl with no args, #42938 patch applied All tests successful, 2 tests and 172 subtests skipped. Files=56, Tests=2488, 72 wallclock secs (51.73 cusr + 11.59 csys = 63.32 CPU) Configure.pl --gc=libc, no patches applied Failed Test Stat Wstat Total Fail List of Failed ------------------------------------------------------------------------------- t/library/string_utils.t 0 6 29 4 28-29 t/op/stringu.t 2 512 25 2 1 19 2 tests and 176 subtests skipped. Failed 2/56 test scripts. 4/2488 subtests failed. Files=56, Tests=2488, 69 wallclock secs (50.57 cusr + 11.19 csys = 61.76 CPU) Failed 2/56 test programs. 4/2488 subtests failed. Configure.pl --gc=libc, #42938 patch applied All tests successful, 2 tests and 176 subtests skipped. Files=56, Tests=2488, 70 wallclock secs (50.67 cusr + 11.24 csys = 61.91 CPU) Mark
