Re: Gnome login performance
- From: Brian Cameron <Brian Cameron sun com>
- To: Brian Cameron sun com, michael ximian com
- Cc: gnome-hackers gnome org, gnome-vfs ximian com
- Subject: Re: Gnome login performance
- Date: Tue, 8 Oct 2002 19:37:43 +0100 (BST)
> > 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
> 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.
] [Thread Prev