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

[Piotr Eljasiak]

> > 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:

        g_thread_init()
        gnome_program_init()
        gnome_vfs_init()
        ...
        gcmd_cfg_load()
        ...
        OWNER_init()                    //      read users and groups
        ...
        

and finally:
        gtk_widget_show (GTK_WIDGET (main_win));
        ...


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).

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...

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.


> > systems, the fix provides MUCH faster mapping uid/gid -> user/group name
> > (using hash tables). As a result now gcmd should be more responsive when
> > reloading or opening new dir :o))
> 
> Opening /usr/bin needs below 0.5 s now, with 
> 
> ~ mi: ls -1 /usr/bin | wc -l
> 2534
> 
> but it comes to my mind this was not correctly benchmarked, since i granted 
> harddisk controller and linux ext3  a warm up to scan the disk, correctly, 
> but not from console but from gcmd. And i guess that put stuff into memory, 
> which would be re-used by gnome-vfs even if i quit and restart gcmd.
> 
> So another try, with 
> 
> ~ mi: ls -1 /usr/share/doc | wc -l
> 1728
> 
> before opening this in gcmd, and guess what. 
> First run slightly more than 1s, second run below 0.5 seconds.
> 
> (Anyway, how could i benchmark the sole gcmd part ? Running both versions 
> through gdb ? Uncool...)
> 
> This tested on a standard 7200 rpm SATA drive, 3G dualchannel RAM, GeForce 
> 7200.

What about adding some timestamps (printed on stderr) to devel branch of
gcmd? It could be controlled with some cmdline options like:
gnome-commander --debug=T