Re: [Nautilus-list] throbber out-of-process

[Maciej Stachowiak <mjs noisehavoc org>]

On 02Aug2001 08:40PM (-0400), Havoc Pennington wrote:
> 
> 
>  - opening a new window and starting up Nautilus is still too slow.
>    The problem may be the same, since starting up involves 
>    creating windows. Oddly, if you "nautilus -q" the session manager
>    will respawn Nautilus almost instantly; I don't know what's 
>    different about this case vs. the normal startup/window-open.
>    But when respawned, Nautilus will be back in only a second or two. 
>    Perhaps it's already paged in and simply sucking all the code off 
>    disk is our main speed problem!
> 
>    We have hit a wall on improving this, because the available
>    profilers simply suck too much. We need something that can give a
>    multiprocess/multithread view of what is going on.  The profiles we
>    can get are just jumbles of assorted small stuff. Sadly a decent
>    profiler and a platform it will run on is really expensive.
> 
>    The fixes we've made to eliminate background of none and expose
>    handling on the desktop dramatically decrease user perception of
>    "brokenness" on startup, at least. When people get bored on startup
>    and start making "window trails" they get a bad impression and file
>    tons of bug reports.

Havoc,

How about trying it with this:

http://gcc.gnu.org/ml/gcc/2001-05/msg01670.html

Nautilus does not use much C++ but it does use a lot of shared
libraries. I bet it will improve startup time for the Nautilus Mozilla
component even more, since Mozilla is C++ _and_ uses a lot of shared
libraries.

 - Maciej

> 
>  - the memory footprint is a bit too high. I haven't profiled this to
>    see what can go. It's not that bad, but it's not as good as it
>    should be yet.
> 
>    I'm hoping that with GTK 2 we can nuke the whole smooth font
>    subsystem, nuke things like EelImageChooser, and just generally
>    blow away a bunch of code in favor of stock stuff. This should
>    shrink the footprint, reduce maintenance burden, and get
>    i18n/keynav/accessibility to work with fewer headaches.
> 
>    Of course some GTK things have gotten slower, so maybe it'll 
>    just all wash out.


Have you tried checking out how much of the memory is constant
overhead and how much depends on how large a directory you are
viewing? Perhaps it's possible to make some of the data structures
more space-efficient.

Regards,

Maciej