On 06/15/2011 08:24 AM, Timo Teräs wrote: > On 06/15/2011 01:10 AM, Bernhard Reutner-Fischer wrote: >>> Duh. It looks like the bb_get_chunk_with_continuation always allocates >>> new memory for the returned string. That could be kinda slow. It'd be >>> faster if the line reading buffer was allocated only once (and grown >>> only when necessary). >>> >>> But this realloc/free business is probably another culprit that has >>> global effect. Some one should redesign bb_get_chunk_with_continuation >>> so it can be used with pre-allocated buffers. >> >> http://git.uclibc.org/uClibc/tree/libc/misc/internals/parse_config.c#n58 > > Great. So uClibc and busybox variants are that much diverged. > > [ot] The uClibc variant is suboptimal too, since it's using strchr for > finding '\n' which is known always to be the last character in the > string if present. > > Anyone interested to fix the busybox line reader which is the more > broken one?
Rabbit hole goes deep. It's the whole family of reading lines in libbb that's brain damaged this way. xmalloc_fget*. In the sources there's even faster versions, disabled for some reason. I also remember that there was issue with fgets, that it didn't detect NUL bytes properly, and was broken if the file has \0 and or \n as separator. It seems that the whole API of reading lines needs a rework, and it would speed up a bunch of bb tools. I might take a look at it today, if I'm feeling that I need to optimise stuff. ;) - Timo _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
