rms@AI.MIT.EDU (Richard Stallman) (01/30/91)
This idea would make the directory look cleaner, but it might have a serious disadvantage, which is to slow down the search for files to be loaded. Maybe the cost won't be enough to be noticeable. If you give it a try, please let me know. The most interesting case to test would be when fetching the Lisp files via NFS from a fairly loaded server.
kyle@wendy-fate.uu.net (Kyle Jones) (02/02/91)
rms@AI.MIT.EDU (Richard Stallman) writes: > This idea would make the directory look cleaner, but it might have a > serious disadvantage, which is to slow down the search for files to > be loaded. This slowdown can be eliminated if we just reorganized the Lisp sources and left the byte-compiled code in a directory to itself. In fact we should see some speedup since the directory will be smaller.
abrown@hpcvca.CV.HP.COM (Allen Brown) (02/05/91)
> rms@AI.MIT.EDU (Richard Stallman) writes: > > This idea would make the directory look cleaner, but it might have a > > serious disadvantage, which is to slow down the search for files to > > be loaded. kyle@wendy-fate.uu.net (Kyle Jones) writes: > This slowdown can be eliminated if we just reorganized the Lisp > sources and left the byte-compiled code in a directory to itself. > In fact we should see some speedup since the directory will be > smaller. And some libraries could be slowed down without affecting serious uses of emacs. I refer to the many games packages. This should speed up the other packages. -- Allen Brown abrown@cv.hp.com or abrown%hpcvca@hplabs.hp.com or hplabs!hpcvca!abrown or "Hey you!" Not representing my employer. "Oy yam wot oy yam, an at's all wot oy yam." --- Popeye
ses%TECHUNIX.BITNET@MITVMA.MIT.EDU (Simon E Spero) (03/03/91)
rms@AI.MIT.EDU (Richard Stallman) writes: > serious disadvantage, which is to slow down the search for files to > be loaded. kyle@wendy-fate.uu.net (Kyle Jones) writes: > This slowdown can be eliminated if we just reorganized the Lisp > sources and left the byte-compiled code in a directory to itself. > In fact we should see some speedup since the directory will be > smaller. Wouldn't splitting off the .elc files break thinks like byte-recompile-directory? I can't see any problem at all with the longer load-path. My standard load-path has about twelve elements (many of which don't exist on any given machine). Even when they are all there, the search time is negligiggle. When I wrote my patch to info.el to work with multiple info directories, I was effectively doing the same work as load-library finding files ( x/file x/(downcase file) x/file.Z x/(downcase file).Z .) I found no noticeable degradation in performance. Talking about info files, if you're going to be splitting up the lisp directory, mightn't it be an idea to split up the info directory as well? Many major packages like vip, gnus, vm, etc. provide their own texinfo files. If the plan is to separate major packages, then shouldn't the info files live in the same place as the elisp files? Will version 19 provide multiple Info-directories? The stand-alone info reader almost Does The Right Thing here, although it still replies on a single dir file for all directories. Simon ---- ses@techunix.technion.ac.il | Latest Score: Israel 4, Iraq nil ses@techunix.bitnet |`Might as well face it, you're addicted to scuds' ------------------------------------------------------------------------------ Tel +272-4-292658, Fax +272-4-236212, Tlx 46406 |A Corner of a Foreign field.