Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!munnari.oz.au!sirius.ucs.adelaide.edu.au!augean!sibyl!ian
From: ian@sibyl.eleceng.ua.OZ (Ian Dall)
Newsgroups: comp.arch
Subject: Re: Tradeoffs
Message-ID: <672@sibyl.eleceng.ua.OZ>
Date: 10 Jun 90 01:31:24 GMT
References: <640@sibyl.eleceng.ua.OZ> <2662CE6C.3E68@tct.uucp> <26798@eerie.acsu.Buffalo.EDU> <266576A7.6D17@tct.uucp> <9494@pt.cs.cmu.edu> <1990Jun3.041822.13548@utzoo.uucp> <27416@eerie.acsu.Buffalo.EDU> <.5X3-ZB@xds13.ferranti.com> <671@sibyl.eleceng.ua.OZ> <13684
Reply-To: ian@sibyl.OZ (Ian Dall)
Organization: Engineering, Uni of Adelaide, Australia
Lines: 41

In article <136844@sun.Eng.Sun.COM> martyi@sun.UUCP (Marty Itzkowitz) writes:
}In article <671@sibyl.eleceng.ua.OZ> ian@sibyl.OZ (Ian Dall) writes:
}>
}> In a running emacs it is easier to get
}>a process size of over 2MB. Most of this is due to the number of files
}>visited. In some ways, emacs method of reading in all of every file
}>visited seems wasteful, but in practice it is not too bad. One
}>alternative is to make (allow) the user two only read in "pages" of a
}>file at a time. That is certainly workable, but is not transparent.
}>Another alternative is to automatically read in sections of files as
}>necessary and, if necessary, write out data to temporary files.
}>Surprise, surprise, that is almost exactly what a virtual memory
}>operating system does. So why not *let* the virtual memory operating
}>system do it? (*) Why does it matter that "ps" shows a large number for
}>the process size?
}
}The main argument for NOT letting the virtual memory system deal with it
}is that the program has a much better idea of an appropriate strategy
}for page replacement than the OS can infer from past behavior.  When the
}user switches to a new file the editor can infer that the pages from the
}previous edit can be discarded,

It would probably be inferring incorrectly. I very frequently hop back
and forth between a foo.c file and a foo.h file (for example). The
only way emacs could resonably know that you didn't want a buffer
again is if you killed it. Some variant of LRU is probably about as
good as emacs could do.  There might be something special about
editors which requires a different paging strategy than the OS, but
you haven't identified it.

There is the potential that you might only want to access a small part
of a file, in which case emacs strategy of reading it all in is a
waste (of IO bandwidth rather than memory), but in practice you find
the bit of the file you want by searching or scrolling, which accesses
the whole file anyway. Some improvement could be made by mmap'ing
files but I wouldn't expect a *big* improvement. Note that the mmap
method still results in chewing a lot of virtual memory.

-- 
Ian Dall     life (n). A sexually transmitted disease which afflicts
                       some people more severely than others.