Speed sensation

[Roger Larsson]

On tisdag 15 april 2003 23:10, Eray Ozkural wrote:
> On Tuesday 15 April 2003 21:43, Dirk Mueller wrote:
> > the problem is not actually the time it runs but the time it does not run,
> > because the kernel has something else to do (search files, read data, mmap
> > libraries, resolve symbols). gprof does not compute this, therefore its
> > totally useless as debugging method for this case.
> 
> Hmm, this brings to my mind the possibility of running some of the startup 
> tasks in parallel so that we can work around system blocks and utilize CPU 
> better. Probably not too much to be gained but still if there is I/O, it 
> could be possible to overlap I/O with CPU (at least in theory!)
> 

This will probably make it SLOWER!

Why?

During startup most processes are IO bound.
1) Waiting for program to load.
2) Waiting for library code to load
3) Waiting for configuration files to be read
4) Waiting for startup (including their IO wait)
   of other programs (X, fontmanagers, ...)

Starting more programs in parallell will lead to more disk seeks (concurrent 
accesses to more files) - and disk seeks is the killer...

If you have a machine with LOTS of RAM (256MB is not enough) you can test
test this.
* Time KDE startup from a cold machine.
* Log out.
* Time another KDE starup (no restart of computer).
  This time files are in Linux file cache.

What to do?
* Don't demand page text (code) on computers with enough memory.
  [See message from Andrew Morton below]
* Use less configuration files, i.e a registry :-(
  - A registry is a single point of failure.
  - Hard to edit and search with ordinary tools.
  + Fewer disc accesses, as long as it is continous on disk...

  Well I do not like that but a persistent configuration file cache...
  (but it is costly to check that the cache is consistent...)
  Or gzip:ing all configuration files in .kde to one .gz

On fredag 17 januari 2003 06:34, Andrew Morton wrote:
> 
> The cost of reading all the blocks in a file is negligibly higher than
> reading (say) half of them.
> 
> For example, this script:
> 
> 	#!/bin/sh
> 	PROG=$(which $1)
> 	for lib in $(ldd $PROG | cut -d ' ' -f 3)
> 	do
> 	        cat $lib > /dev/null
> 	done
> 	$*
> 
> when used as
> 
> 	./launch.sh konqueror
> 
> speeds up the initial launch of konqueror by maybe 2x (didn't bother 
benching
> it too hard, but the difference is quite plain).
> 
> And it's reading all the debug info and other ELF gunk.  Clearly, performing
> an MADV_WILLNEED against the entire executable/library as soon as it is
> mapped will speed things up significantly.  It's saving a ton of seeks.
> 
> As the amount of memory and disk bandwidth continue to increase, and the
> latency of disk seeks and rotation fails to keep up, demand paging just 
makes
> less and less sense.

Andrew, have you forwarded this to ELF and lib folks?

/RogerL

-- 
Roger Larsson
Skellefteå
Sweden