Re: [gcmd-dev] [FIX] problem #567506 (slow startup for systems with many users)

[Michael]

Piotr:
> > > Rev. 2478 fixes problem #567506. Apart from making startup faster on big
> > 
> > yes, definitely faster. 
> > Just curious, what was the crucial resource in this case ? 
> > Parallel memory access ? Cutting obsolete tests ?
> 
> The former code was pretty straightforward:
>         ...
>         OWNER_init()                  //      read users and groups
>         ...
> 
> OWNER_init() retrieved info on every user/group in the system, so later
> mapping uid/gid -> user/group name was possible. Unfortunately, for
> systems with lots of users (~40k) the startup took quite a while (~1
> min).

You mean it's a recursive lookup ?

> The current implementation reads user/group info on request only
> (typically only a few queries), and with good luch it takes milliseconds
> only (the bad luck is when you start in /home dir ;o). The rest
> information is bulk-read in separate thread AFTER showing gcmd window,
> so it's not crucial any more...

That's a nice idea.

I started gcmd from shell with  -l /home -r /var --debug=acdfgiplmnsvwyzx and 
it was there nearly immediately.

Anyway, gcmd seems to be rather busy with refing stuff like 

[FF] refing: 0x0x1d20b60 .netxrc to 2
[FF] refing: 0x0x1d35800 .xinitrc to 2
[FF] refing: 0x0x1d35860 .glamerc to 2
[DD] refing: 0x0x1d0dac0 .subversion to 3
[DD] refing: 0x0x1d0db70 .mozilla to 3

It's another question why the column 'uid' and 'gid' has to resolve users, i 
think this could be a 'format' option and it should be always done in the 
alt+enter info dialog. But there's no need to assume anybody wants it as 
default. Lots of people would not activate the respecitve column anyway, and as 
for server admins, it's nearly as good to see numbers, it's much more easy to 
sort after that.
 
> The replacement of the old list (used as container for uid/gid) with
> hash list gave extra bonus - finding uid/gid -> user/group name is VERY
> fast now.

Good !