Re: [Nautilus-list] Change committed that may affect the slowness

[Seth Nickell <snickell stanford edu>]

On Sat, 2001-10-13 at 15:18, Seth Nickell wrote:
> > Try running it under the debugger and hit Control-C while the UI is
> > frozen. Then see if you can figure out what it's blocking on from the
> > backtraces of the various threads (I recommend `cont' as a way to
> > switch threads (it will keep stopping until you cycle through all the
> > threads) rather than the actual gdb way to do it, the latter is
> > somewhat unreliable.
> 
> yeah, I was looking at this last night but its not telling me anything.
> 
> There are 11 threads, 8 of which are inactive threads waiting in the
> GnomeVFS thread pool, one of which is the pthread manager, one of which
> is the nautilus main loop. The only interesting thing I see is one
> thread performing the directory count. The Nautilus main loop seems to
> behaving as per normal.
> 
> I was totally wrong about the UI freezing though. The UI continues to be
> responsive even during the long pause where the throbber has stopped but
> the elements have yet to display. I can even click on the several icons
> that displayed before the "pause" and drag them around.
> 
> The only thing that occurs to me is that Nautilus could be waiting to
> display until the directory counts are finished (?). I have yet to see
> directory counts bubble in after display like I used to, but that could
> be coincidental (e.g. something is freezing and the extra time means the
> directory counts always finish).

hmm... another interesting thing is that the CPU usage by Nautilus is
almost non-existant during the long waiting period. It sits around 6%,
which might support the notion that its waiting for disk access.

-Seth