2:43 a.m.
My XEmacs packages are installed on a Linux machine.
Those packages are used from both Linux and from Solaris.
The Linux NFS server is notoriously slow.
Each find-file of a C source file on Solaris was annoyingly slow.
I tracked it down to this ancient code in one of my cc-mode hooks:
(ignore-errors (require 'cc-lobotomy) ...)
There is no such .el file on my load-path, so a full load-path search
was performed for every find-file.
Anyways, the search of my load-path executes 158 stats, and takes
anywhere from 3-12 seconds, averaging around 5 seconds. This is on
fast machines with an unloaded network.
Many of us on xemacs-beta are using XEmacs with all files on local
disk. In the real world, XEmacs is much more likely to be housed on
NFS-mounted filesystems on an overloaded network. We should work
under the assumption that the price of the current load-path layout is
TEN SECONDS in startup time. This is too expensive.
Martin
3:17 a.m.
On Mon, May 11, 1998 at 06:43:20PM -0700, Martin Buchholz wrote:
My XEmacs packages are installed on a Linux machine.
Those packages are used from both Linux and from Solaris.
The Linux NFS server is notoriously slow.
AFAIK, this is fixed in the experimental kernel line. This is
irrelevant anyway :-)
Many of us on xemacs-beta are using XEmacs with all files on local
disk. In the real world, XEmacs is much more likely to be housed on
NFS-mounted filesystems on an overloaded network. We should work
under the assumption that the price of the current load-path layout is
TEN SECONDS in startup time. This is too expensive.
Three possibilities that I can see:
- cat the auto-autoload and the dumped-lisp files together, put
everything in one directory, reduce the load-path to two or three
directories. This breaks the packaging, unless you implement that
mainly with a forest of symbolic links. But afaik, symbolic links
aren't available in winblows.
- cache the directories content list in memory at startup, update it
automatically by checking for a directory date change when an
unknown file is asked for or an accessed cached file is absent. Then
fight with buggy NFS implementations
- same as 2, but cache on disk (aka, kpathsea). This also accelerates
startup.
My personal feeling is that anything different than the first solution
should wait for 21.1.
OG.
3:29 a.m.
Some time ago, Martin Buchholz wrote...
|+
| My XEmacs packages are installed on a Linux machine.
| Those packages are used from both Linux and from Solaris.
| The Linux NFS server is notoriously slow.
| Each find-file of a C source file on Solaris was annoyingly slow.
| I tracked it down to this ancient code in one of my cc-mode hooks:
|
| (ignore-errors (require 'cc-lobotomy) ...)
|
| There is no such .el file on my load-path, so a full load-path search
| was performed for every find-file.
I think that Fload may be hacked so it caches misses. If the cache
is flushed on every redisplay, this is pretty safe, but would greatly
help avoid problems like this. Maybe flushing may be done even more
intelligently.
At all, stats on NFS are known to be very expensive. XEmacs probably
needs some general filesystem caching mechanism.
Kirill
6:45 a.m.
>>>> "kkm" == Kirill M Katsnelson
<kkm(a)kis.ru> writes:
kkm> Some time ago, Martin Buchholz wrote...
kkm> |+
kkm> | My XEmacs packages are installed on a Linux machine.
kkm> | Those packages are used from both Linux and from Solaris.
kkm> | The Linux NFS server is notoriously slow.
kkm> | Each find-file of a C source file on Solaris was annoyingly slow.
kkm> | I tracked it down to this ancient code in one of my cc-mode hooks:
kkm> |
kkm> | (ignore-errors (require 'cc-lobotomy) ...)
kkm> |
kkm> | There is no such .el file on my load-path, so a full load-path search
kkm> | was performed for every find-file.
kkm> I think that Fload may be hacked so it caches misses. If the cache
kkm> is flushed on every redisplay, this is pretty safe, but would greatly
kkm> help avoid problems like this. Maybe flushing may be done even more
kkm> intelligently.
The current caching algorithm is actually quite reasonable. It just
degrades when the number of directories in the search path grows without bound.
(length load-path)
==> 83
kkm> At all, stats on NFS are known to be very expensive. XEmacs probably
kkm> needs some general filesystem caching mechanism.
My main point is that many of our users will have to wait an extra 10
seconds at startup, or whenever searching for a lisp library that is
not found. Neither is acceptable.
Martin
ObBench: Packages initialization adds 12 sec to XEmacs startup time.
The sleep's below are for Solaris/Linux NFS caches to time out.
$ repeat 10 time env EMACSPACKAGEPATH=/root ./xemacs -no-site-file -no-init-file -f
kill-emacs && sleep 60
env EMACSPACKAGEPATH=/root ./xemacs -no-site-file -no-init-file -f kill-emacs 0.27s user
0.11s system 2% cpu 16.065 total
env EMACSPACKAGEPATH=/root ./xemacs -no-site-file -no-init-file -f kill-emacs 0.32s user
0.06s system 2% cpu 13.674 total
env EMACSPACKAGEPATH=/root ./xemacs -no-site-file -no-init-file -f kill-emacs 0.35s user
0.07s system 2% cpu 16.332 total
env EMACSPACKAGEPATH=/root ./xemacs -no-site-file -no-init-file -f kill-emacs 0.31s user
0.09s system 2% cpu 17.360 total
env EMACSPACKAGEPATH=/root ./xemacs -no-site-file -no-init-file -f kill-emacs 0.34s user
0.14s system 2% cpu 17.274 total
env EMACSPACKAGEPATH=/root ./xemacs -no-site-file -no-init-file -f kill-emacs 0.52s user
0.19s system 4% cpu 15.611 total
env EMACSPACKAGEPATH=/root ./xemacs -no-site-file -no-init-file -f kill-emacs 0.47s user
0.19s system 10% cpu 6.358 total
env EMACSPACKAGEPATH=/root ./xemacs -no-site-file -no-init-file -f kill-emacs 0.28s user
0.10s system 2% cpu 15.424 total
env EMACSPACKAGEPATH=/root ./xemacs -no-site-file -no-init-file -f kill-emacs 0.34s user
0.19s system 3% cpu 17.472 total
$ repeat 10 time ./xemacs -no-site-file -no-init-file -f kill-emacs && sleep 60
./xemacs -no-site-file -no-init-file -f kill-emacs 0.92s user 0.23s system 4% cpu 26.682
total
./xemacs -no-site-file -no-init-file -f kill-emacs 0.65s user 0.31s system 3% cpu 25.849
total
./xemacs -no-site-file -no-init-file -f kill-emacs 0.52s user 0.26s system 2% cpu 26.787
total
./xemacs -no-site-file -no-init-file -f kill-emacs 0.83s user 0.25s system 4% cpu 24.658
total
./xemacs -no-site-file -no-init-file -f kill-emacs 0.67s user 0.24s system 3% cpu 24.445
total
./xemacs -no-site-file -no-init-file -f kill-emacs 0.84s user 0.24s system 3% cpu 28.127
total
./xemacs -no-site-file -no-init-file -f kill-emacs 0.68s user 0.25s system 3% cpu 24.599
total
./xemacs -no-site-file -no-init-file -f kill-emacs 0.49s user 0.18s system 2% cpu 23.756
total
./xemacs -no-site-file -no-init-file -f kill-emacs 0.76s user 0.30s system 4% cpu 21.710
total
9693
days inactive
9693
days old
3 comments
3 participants
participants (3)
-
Kirill M. Katsnelson -
Martin Buchholz -
Olivier Galibert