Re: gnome-vfs performance patch

[Michael Meeks <michael ximian com>]

Hi Alex,

On Tue, 2002-10-22 at 08:30, Alexander Larsson wrote:
> I had a quick look at this. Aren't we switching one performance problem 
> for another? The fallback to default_callbacks/default_async_callbacks 
> needs to take the callback_table_lock, which serialize an otherwise 
> lock-less codepath. I'm not sure how much this code is called and how much 
> the default callbacks are used, but someone obviously spent lots of time 
> making it lock-less.

	And in the process consumed 5% of the CPU during nautilus startup :-)

	Ultimately - yes, this does add a smidgen more locking to a codepath
that is fairly unsual: callback invocation, typically used with slow
remote protocols and/or user authentication - neither of which require
blinding speed AFAICS.

	OTOH - it removes a load of dynamic allocation [ all of which has to be
locked & thread-safe ] to _every_ job dispatch.

	So - on the whole, it seems to me we replace just tons of heap /
g_hash_table related locking on the critical path with a tiny amount of
locking on the uncommon path :-)

> What i find strange is that the hash-table copying could take that much 
> time. Unless i'm missreading this the two hash tables should (in the 
> nautilus case) have had two entries each. I find it hard to believe that 
> copying four strings took 5.6 seconds. Aren't we looking at the wrong 
> thing here?

	Well - it happens per job dispatched, ie. every (async?) VFS call - cf.
gnome_vfs_job_set -> gnome_vfs_module_callback_get_stack_info which [ in
addition to dupping lots of strings ], also, stores essentially the same
stuff in great chunks of memory. On large systems, we've seen > <max fd>
async jobs queued at once - thus this results in a fair whack of wasted
memory too.

	I think Brian's patch is correct, and we should get it into stable and
HEAD asap, and enjoy a smoother vfs experience :-)

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot