Kevin Ryde <[EMAIL PROTECTED]> writes:
> I think I'll do this in the 1.6 branch too.
Yes, sounds good.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailma
Alan Grover <[EMAIL PROTECTED]> writes:
>
> A 1mb string takes 22 allocations/moves (~15000 under the previous
> code),
Yep, 15000 being so slow that you think it's gone into an inf loop
:-).
___
Guile-devel mailing list
Guile-devel@gnu.org
http://list
Exponential growth set off a warning bell for me, but you probably have
other problems by the time it bites you (consider what you are doing to
the page-cache when you copy to the new block).
After about the 6th allocation, things converge such that 1/6 of that
total allocation is unused on averag
I made the change below, it leaves the code alone, just grows the
buffer more each time, by a factor 1.5x so copying time is no longer
quadratic in the output size.
I think I'll do this in the 1.6 branch too. Backtraces there have
been slow to the point of unusable for me in some parsing stuff I'
Kevin Ryde <[EMAIL PROTECTED]> writes:
> But I don't know if the read side bits of this change are right. Is
> it supposed to update read_pos, read_end and read_buf_size to be the
> end of the string, or something?
I don't know. Could you try to figure this out yourself?
--
GPG: D5D4E405 - 2F
