Date: Wed, 07 Feb 2001 19:16:15 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: broeker AT physik DOT rwth-aachen DOT de
Message-Id: <2950-Wed07Feb2001191615+0200-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
CC: djgpp AT delorie DOT com
In-reply-to: <Pine.LNX.4.10.10102071554500.4137-100000@acp3bf> (message from
	Hans-Bernhard Broeker on Wed, 7 Feb 2001 16:08:53 +0100 (MET))
Subject: Re: Function and File ordering and speed optimization
References:  <Pine DOT LNX DOT 4 DOT 10 DOT 10102071554500 DOT 4137-100000 AT acp3bf>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Wed, 7 Feb 2001 16:08:53 +0100 (MET)
> From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
> 
> On Wed, 7 Feb 2001, Eli Zaretskii wrote:
> 
> > Keeping frequently-used code together improves the locality of the code, 
> > exactly as referencing a large array in order improves the locality of 
> > data.  When your program or your OS pages, this really makes a 
> > difference.
> 
> I think it only is going to make a noticeable difference if the active
> code set is already very close (within a few 4KB pages) to the amount of
> free memory. In such a situation, reducing the memory footprint might
> indeed help to avoid paging altogether, and thus speed up things. But I
> doubt there are enough programs that fulfill these conditions to be worth
> bothering about this type of optimization.

So you are saying, in effect, that improving locality of data
accesses, like accessing a 2-dimensional matrix in the order of
storage, is a waste of effort?

My experience is different.  At least on Windows, when Emacs starts
garbage collection (which requires it to touch every page of its
address space), the system pages frantically for several long seconds.
In contrast, most of the rest of time I don't see the disk work too
much, although the free physical memory indicator most of the time
shows zero (that's a 64MB machine, and I leave Emacs running for days
without shutting it down, so it uses lots of memory).

> Let's face it: once the system starts to page stuff in and out on a
> somewhat regular basis, all optimization is moot.

All optimzations are moot, except those optimizations which make it
page less.