On Mon, 2006-01-09 at 11:41 -0500, Lee Revell wrote:
> On Mon, 2006-01-09 at 17:29 +0100, Bernd Petrovitsch wrote:
> > On Mon, 2006-01-09 at 11:19 -0500, Lee Revell wrote:
[....]
> > > I think you'll get at most a 10% or 20% speedup by improving the kernel,
> > > while some of these apps (think Nautilus vs Windows Explorer) will need
> > > to be 1000% faster to seem reasonable to a Windows user.
> >
> > That's easy: Just start nautilus, OOorg, Firefox, a java-vm and
> > GNOME/KDE infrastructure at login time in the background (*eg* and
> > mlockall() the more important ones so that the are surely in RAM) and
> > "starting the app" is only a small program connecting to the respective
> > process to get a fork() there (e.g. like the "-remote" parameter in the
> > Mozilla family).
>
> Have you tried this? I suspect it still takes at least twice as long as
> on windows.
No, I don't run all on them at once (only xemacs, firefox and the above
forgotten evolution on XFCE) and if, the hosts I'm usually working on
have probably not enough RAM for mlockall(MCL_CURRRENT).
And AFAIK there are no small starter programs and features - only for
Mozilla and cousins.
> For example on my system there was already a "nautilus" process but
> "Places -> Home Folder" still took ~2 seconds to display anything, and
> ~8 seconds to completely render the window and icons. On Windows this
> takes much less than a second.
Hmm, what happens on the click:
- The click is transported via X, TCP/IP to the application.
- The app decides what to do and generates anew window and content.
- If swapped out, swap it in.
- Load the home directory and what else is needed for displaying it
(Icons, etc.) from the disk.
- Load these images into the X server.
Id a completely new progrma is started, you must load it from disk, wait
for the shared linker, let it initialize everything and *then* it is
actually usable (and I hate that default OO.org feature that it puts the
window in foreground after startup at least three times until the
document is loaded).
If you have a memory hog like firefox with a large page loaded then lots
of RAM are occupied anyways and no one except firefox can do anything
about it (without swapping out and this is also slow). And I have just
to switch tabs to hear my disk working.
Ths point is: You have to analyze *where* the apps spend that much time
(independent of being idle wehile waiting for disk I/O or busy moving MB
of graphic data around). It doesn't make that much sense to improve the
(e.g.) 2% in the kernel by 50% since that would bring next to nothing.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
