From: Andi Kleen <ak@muc.de>
To: Emil Briggs <briggs@bucky.physics.ncsu.edu>
Cc: linux-mm@kvack.org
Subject: Re: Application load times
Date: Mon, 31 May 1999 21:54:38 +0200 [thread overview]
Message-ID: <19990531215438.B3037@fred.muc.de> (raw)
In-Reply-To: <199905311911.PAA13206@bucky.physics.ncsu.edu>; from Emil Briggs on Mon, May 31, 1999 at 09:11:08PM +0200
On Mon, May 31, 1999 at 09:11:08PM +0200, Emil Briggs wrote:
> Are there any vm tuning parameters that can improve initial application
> load times on a freshly booted system? I'm asking since I found the
> following load times with Netscape Communicator and StarOffice.
>
>
> Communicator takes 14 seconds to load on a freshly booted system
>
> On the other hand it takes 4 seconds to load using a program of this sort
>
> fd = open("/opt/netscape/netscape", O_RDONLY);
> read(fd, buffer, 13858288);
> execv("/opt/netscape/netscape", argv);
>
> With StarOffice the load time drops from 40 seconds to 15 seconds.
>
>
> The reason this came up is because I installed Linux on a friends
> computer who usually boots it a couple of times a day to check email,
> webbrowse or run StarOffice -- they immediately asked me why it
> was so slow. Since I know how they usually use their computer it was
> easy enough to remedy this with the little bit of code above. Anyway
> does anyone know if there a more general way of improving initial load
> times with some tuning parameters to the vm system?
The reason is that the read can use the disk bandwidth fully including
read-a-head, which the execv reads the block in the order the functions
which are called at loadup are laid out in the executable. This is especially
bad which C++ programs which usually have small constructors spread out
all over the file, which are called at boot up. The solution are special
programs which rearrange the executable and lay out the function on
page boundaries to minimize the working set and load time.
These programs exist for most other OS with various names (e.g. pixie on
Irix). Not on Linux yet. Nat Friedman apparently presented a design for
"grope" on the LinuxExpo, but it isn't released yet.
2.2 made program loading already quite a bit faster by introducing readahead
for mmap.
-Andi
--
This is like TV. I don't like TV.
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
next prev parent reply other threads:[~1999-05-31 19:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-05-31 19:11 Emil Briggs
1999-05-31 19:33 ` Matthew Kirkwood
1999-06-01 0:19 ` Stephen C. Tweedie
1999-05-31 19:54 ` Andi Kleen [this message]
1999-06-05 6:10 ` Vladimir Dergachev
1999-06-01 12:51 Emil Briggs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19990531215438.B3037@fred.muc.de \
--to=ak@muc.de \
--cc=briggs@bucky.physics.ncsu.edu \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox