On Wed, Jun 15, 2011 at 04:47:39PM +0300, Timo Teräs wrote: > > In any case, the difference is *very* small at least on x86 (including > > SMP/multicore). The cost of the "lock xchg" vs "if (threads>1)" is > > something like 50 cycles, and if I remember right, making my > > implementation always perform locking only slowed it down by about > > 20%. (I say only because this translates into very small difference in > > total program time unless your program is "for (;;) free(malloc(1));") > > > > Perhaps the cost is much larger on other archs where atomics are more > > expensive... > > The figures depend on the specific application. > > But still, why do malloc() ... free() in relatively tight inner loop, if > there's a clean way to avoid it? I don't see point doing "fast things" > when we don't have to do them at all. When reading 100.000 or a million > lines file, avoiding that many malloc/free calls (or more) is visible on > execution time.
Presumably because you don't know in advance the maximum line size you might need. I doubt this really matters for reading config files, but I also doubt that I'm qualified to make that decision for a project I'm not actually a developer on.. By the way, getdelim normally can reuse an existing buffer as long as you keep track of the size of it; it only has to reallocate if it needs more space. > Though, in bb config_* API, getdelim isn't always enough. They seem to > need a special line reader that treats both \0 and \n as line terminator. Why? \0 is not valid in text files and certainly shouldn't appear in config files... What is it needed for? Rich _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
