[PATCH 3/3] parse_config: use getline to read config

[Timo Teräs]

On 06/20/2011 11:18 AM, Denys Vlasenko wrote:
>>> Can you send me timing results and bloatcheck for both patches?
>>>
>>> How much speedup you get if you use getc_unlocked instead of getline
>>> (see attached patch)?
>>
>> Your patch doesn't work. You probably meant #ifdef *_unlocked. But that
>> doesn't work either as those are functions, not #defines. I did try just
>> one line change in parse_config.c changing getch to _unlocked.
> 
> Does not work in which way? (and yes, I meant ifNdef).
> I pushed it to git, btw...

Oh, right the comment explains it. Though, not all platforms support
*_unlocked.

man unlocked_stdio (3) says:

The four functions getc_unlocked(), getchar_unlocked(), putc_unlocked(),
putchar_unlocked() are in POSIX.1-2001.

The nonstandard *_unlocked() variants occur on a few Unix systems, and
are available in recent glibc. They should probably not be used.

Though uclibc does them pretty well too. But definitely not all
platforms bb builds for support them.

Should probably have some HAVE_UNLOCKED_STDIO flag in platform.h for this.

>> As suggested by Rich, unlocked is a speed up, but not as major as
>> getline. And both, hashing and getline give a considerable speed up here.
> 
> Applied both to git. Thanks!
> 
>> Tests run on moderate laptop (Core2 Duo T7300, 2*4000 bogomips), running
>> Linux Mint (= glibc). Against standard kernel modules.dep which is 300kB
>> or 3075 lines. getline speed-up on uclibc is not probably as large,
>> since uclibc getline is lame and needs performance optimization as
>> noticed before. Actually, same applies to also fgets/gets in uclibc. All
>> the line readers suck there as they use getc_unlocked() loop instead of
>> doing memchr on the buffer.
> 
> I bet Bernhard will be happy :)
> 
>> Thinking also more, if using fgets instead of getline, the resulting
>> code might be slightly smaller in size. As the getline implementation
>> needs two line buffers for the continuation handling.
> 
> Most lines in config files don't have continuation.

Nope. But this to result in *size* optimization, not speed... (The speed
affect is two edged: fgets implementation does more locking, but less
memcpy'ing as we could also read the data directly to right place in
memory and avoid the second memcpy... I would suspect fgets would be
also faster too).

- Timo