Re: Gnome login performance

[Brian Cameron <Brian Cameron sun com>]

Michael:

> > nautilus: 3.210 seconds user, 30.850 seconds system
> > 
> >    5.620 system seconds
> >       gnome_vfs_module_callback_use_stack_info
> >          g_hash_table_foreach
> >             static function
> >                g_strdup
> >                   g_malloc
> 
> 	So: ~20% of the time is spent doing this module_callback stuff.
> Extremely odd - I've read the code, and it looks like it's used to allow
> hooks for user authentication on a 'default' and 'per request' basis,
> and custom hooks for various http states.

Note that gnome_vfs_module_callback_use_stack_info is called from
gnome_vfs_job_execute.  That's as high up the stack that Forte analyzer
gives useful info.

> 	As such - it seems a massively dis-proportionate cost to pay. Quite why
> we go to all this effort to copy the default callbacks, and mess around
> with per thread stack stuff is beyond me.
> 
> 	It _looks_ to me as if:
> 
> 	a) We should not copy the default authentication callbacks; if someone
> is relying on the timing of exactly when they set the default callback
> for a certain op [ NB. it can't be un-set etc. ], then they're smoking
> crack and deserve oddness.
> 
> 	b) We maintain a list of push/pop stack operations per thread [ so the
> vfs can be used from multiple threads safely, for every op ]. That's
> fine - we copy that off in gnome_vfs_module_callback_get_stack_info -
> and add the default callbacks.
> 
> 	  Then for reasons that are not clear - we copy the callback table from
> this snapshot back into the per thread operation queue, which
> (presumably) we just copied it from.
> 
> 	  It's not clear to me what's going on there - someone needs to poke at
> it.
> 
> 	c) A push/pop system works nicely in combination with ref counting,
> instead of doing all these deep copies of private callback data - we
> should be (trivially) able to ref / unref them instead; resulting in a
> nice (big) efficiency win.
> 
> 	I hope someone is interesting in picking up some / all of that.
> 
> >    2.370 system seconds
> >       nautilus_directory_get_internal
> >          static function
> >             gnome_vfs_uri_new_private
> >                gnome-vfs_transform_get
> >                   gnome_vfs_configuration_get_module_path
> >                      stat64
> 
> 	Where is nautilus_directory_get_internal called from ? and how many
> times ? clearly doing stat floods is daft; but I never saw this in an
> strace - which makes me curious.

It is called from nautilus_trash_monitor_get which seems to be called
from g_type_create_instance which seems to be called from g_object_newv,
called from g_object_new_valist, called from g_object_new.  That's as far
up the stack that I can go.  :)  Hope this adds some insight into the why.

Brian

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers