On 31 July 2010 17:04, Nicholas Clark <nick@ccl4.org> wrote: > On Fri, Jul 30, 2010 at 11:26:15PM +0200, w.c.humann@arcor.de wrote: >> From: Marvin Humphrey <marvin@rectangular.com> >> Date: 30.07.2010 17:34 >> >>* Why the "+10"? Why have a extra minimum at all? Why "10" instead >> >>of another number? Given your examples, for a large string the 10 is >> >>a trivial fraction of the total and for a small string, the efficiency >> >>either doesn't matter or the string quickly grows into a large string >> >>anyway. >> >> >> > >> >That's similar to my analysis. I think it's more useful to round up to a >> >multiple of the pointer size for small values. >> > >> If I understand correctly (which I'm not certain about), this is done >> anyway right afterwards in >> newlen = PERL_STRLEN_ROUNDUP(newlen); > > That's certainly what the expression in PERL_STRLEN_ROUNDUP() is intended to > do. (Round up to a multiple of the pointer size, so that growth of strings by > small amounts usually avoids repeated realloc() calls for an extra 1 or 2 > bytes). When i saw this I was confused, as I remember when Nicholas wrote the patch that added PERL_STRLEN_ROUNDUP(), and Im wondering why this patch doesnt modify /that/ instead of adding additional logic /in front/ which will then be mixed together.... IOW, it seems like this patch will add some percentage, and then PERL_STRLEN_ROUNDUP will add another percentage of /that/. This doesnt seem right. Whats the problem PERL_STRLEN_ROUNDUP(), and, given that PERL_STRLEN_ROUNDUP() is guarded like so: #ifndef Perl_safesysmalloc_size newlen = PERL_STRLEN_ROUNDUP(newlen); #endif why should this new logic not also be guarded? Surely the intent is to have a mode where Perl doesnt mess with requested size at all? cheers, yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next