11:28 p.m.
A simple comparison:
XEmacs 21.4.14 (latest CVS + my PUI enhancements)
time xemacs -kill
real 0m29.846s
user 0m21.567s
sys 0m1.287s
XEmacs 21.5.15 (latest CVS)
time ./xemacs -kill
real 2m19.488s
user 0m55.854s
sys 0m2.759s
That's pretty horrible.
The 21.4 was configured with:
./configure \
'--extra-verbose'
'--site-prefixes=/usr/local/pgsql:/usr/local/BerkeleyDB.4.1' \
'--dynamic=yes' \
'--with-gtk=no' \
'--with-gnome=no' \
'--with-toolbars' \
'--with-wmcommand' \
'--with-athena=next' \
'--with-menubars=lucid' \
'--with-scrollbars=athena' \
'--with-dialogs=athena' \
'--with-widgets=athena' \
'--with-gif' \
'--with-sound=native,noesd' \
'--with-site-lisp=no' \
'--with-site-modules' \
'--pdump' \
'--with-mule' \
'--with-xfs' \
'--error-checking=none' \
'--with-clash-detection' \
'--cflags=-s -O3 -Wall -march=k6 -malign-double \
-fomit-frame-pointer \
-funroll-loops \
-fexpensive-optimizations \
-fschedule-insns2 \
-D__NO_STRING_INLINES \
-D__NO_MATH_INLINES'
The 21.5 was configured with:
../src/configure \
'--srcdir=../src' \
'--extra-verbose' \
'--site-prefixes=/usr/local/pgsql:/usr/local/BerkeleyDB.4.1' \
'--dynamic=yes' \
'--with-athena=next' \
'--with-menubars=lucid' \
'--with-scrollbars=athena' \
'--with-dialogs=athena' \
'--with-widgets=athena' \
'--with-site-lisp=no' \
'--with-site-modules' \
'--with-mule' \
'--with-xfs' \
'--debug=no' \
'--error-checking=none' \
'--with-clash-detection' \
'--external-widget' \
'--cflags=-O3 -pipe -march=k6 -malign-double \
-fomit-frame-pointer \
-funroll-loops \
-fexpensive-optimizations \
-fschedule-insns2 \
-D__NO_STRING_INLINES \
-D__NO_MATH_INLINES' \
'--use-kkcc'
Yes there are a couple of differences in the two configurations, but
nothing that could account for such a massive slow down.
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| XEmacs - The only _______ you'll ever need. |
| Fill in the blank, yes, it's THAT good! |
|------------------------------<sryoungs(a)bigpond.net.au>---|
2:57 a.m.
>>>> "SY" == Steve Youngs
<sryoungs(a)bigpond.net.au> writes:
SY> A simple comparison: XEmacs 21.4.14 (latest CVS + my PUI
SY> enhancements)
SY> time xemacs -kill
SY> real 0m29.846s
First, did you reboot, then run cold and hot timings? Second, if not,
were there other instances running? Third, what is your platform?
Fourth, are you connected to the net (those times look to me like
you're blocking on a net look up -- you wouldn't happen to have gnus
stuff in your init.el)? On a 450MHz PII with a normally optimized
full error-checking (which mattaers a lot in mule) 21.5.16 plus Xft
(which matters a bit) and some other junk that shouldn't be exercised,
I get
real 0m9.421s
user 0m5.610s
sys 0m0.170s
This is a -vanilla warm start with another instance running, but I
easily get a full desktop.el cold start (boot, log in, XEmacs is
started by xsm) with almost all of the real time spent in font-lock
(about 40 25~150KB buffers being fontified) in 3m30s real time on that
machine. Slow, yes, but I don't see the huge difference that you do
between 21.5 and 21.4.
It really would help if you could give more information about what's
going on in your initialization here. Surely something is horribly
slow for you in 21.5, but unless you tell me I won't know....
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
2:30 a.m.
|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org> writes:
SJT> First, did you reboot, then run cold and hot timings?
No. I suppose a fairer test would have been:
xemacs -kill && time xemacs -kill
SJT> Second, if not, were there other instances running?
No.
SJT> Third, what is your platform?
x86 GNU/Linux
,----[ uname -r ]
| 2.6.0-test11-sy
`----
,----[ /proc/cpuinfo ]
| processor : 0
| vendor_id : AuthenticAMD
| cpu family : 5
| model : 8
| model name : AMD-K6(tm) 3D processor
| stepping : 12
| cpu MHz : 411.525
| cache size : 64 KB
| fdiv_bug : no
| hlt_bug : no
| f00f_bug : no
| coma_bug : no
| fpu : yes
| fpu_exception : yes
| cpuid level : 1
| wp : yes
| flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr
| bogomips : 811.00
`----
,----[ from /proc/meminfo ]
| MemTotal: 78704 kB
`----
SJT> Fourth, are you connected to the net (those times look to me
SJT> like you're blocking on a net look up
Yes, I have a 24/7 ADSL connection.
SJT> you wouldn't happen to have gnus stuff in your init.el)?
Yes, but that's not where the biggest slow down is. I'm getting
murdered in fonts and faces etc.
SJT> It really would help if you could give more information about
SJT> what's going on in your initialization here. Surely something
SJT> is horribly slow for you in 21.5, but unless you tell me I
SJT> won't know....
You can get to all my initialisation files, including Gnus, here:
<http://users.bigpond.net.au/sryoungs/XEmacs/>
The biggest slow down that I can see is in:
<http://users.bigpond.net.au/sryoungs/XEmacs/init-files/fonts-sy.html>
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| XEmacs - The only _______ you'll ever need. |
| Fill in the blank, yes, it's THAT good! |
|------------------------------<sryoungs(a)bigpond.net.au>---|
2:44 a.m.
Steve Youngs <sryoungs(a)bigpond.net.au> writes:
|--==> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
SJT> First, did you reboot, then run cold and hot timings?
No. I suppose a fairer test would have been:
xemacs -kill && time xemacs -kill
When benchmarking, I tend to use `xemacs -batch -f kill-emacs'. The
`-batch' is to avoid measuring the time it takes to map an X window.
However, you might *want* to take that into account, so `-batch' might
not be for you. (But even so, a -batch run will show you whether the
difference comes from the X part or not.)
Maybe XEmacs is waiting for the X server a lot? The `:bold t' thing
sounds like a bunch of calls to `font.el', which might not be
optimized for speed.
4:19 a.m.
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)xemacs.org> writes:
Hrvoje> Steve Youngs <sryoungs(a)bigpond.net.au> writes:
Hrvoje> Maybe XEmacs is waiting for the X server a lot? The
Hrvoje> `:bold t' thing sounds like a bunch of calls to `font.el',
Hrvoje> which might not be optimized for speed.
I don't think this matters. font.el manipulates Lisp structures, and
AFAIK does not itself call X APIs. If there is optimization to be
done, it should be done at a lower level. And the `:bold t' thing
stinks of custom, which _has_ been partially synched to recent GNU by
somebody who wasn't entirely sure of what he's doing (ie, blame me not
custom, but custom code may be one place to look).
What might kill you is huge numbers of calls to XLoadQueryFont and
friends. The X API is designed so that those should be called lazily
by the app. They're all roundtrip requests. (I'm pretty sure that
the output of XListFonts is cached at C-level, but maybe something
goes wrong with that.)
More likely the problems are in cus-face.el or faces.el
(make-face-bold and friends). But even so ... I don't think it's
possible to batch calls to the font APIs effectively, so unless XEmacs
is making multiple queries for non-existent fonts or something?
And of course this doesn't explain why 21.5 would be slower than 21.4;
I don't think the C-level X font handling has changed since 21.4.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
2:06 a.m.
Steve Youngs <sryoungs(a)bigpond.net.au> writes:
|--==> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
SJT> First, did you reboot, then run cold and hot timings?
No. I suppose a fairer test would have been:
xemacs -kill && time xemacs -kill
On my system here at home:
Linux zion.rcn.com 2.4.23 #4 SMP Sun Nov 30 22:17:24 EST 2003 i686 unknown unknown
GNU/Linux
(dual processor 450MHz P3), I killed all my XEmacs and ran the
following tests with the latest versions from CVS:
-vanilla:
xemacs-21.4-2003-11-07
./$d/bin/xemacs -vanilla -kill 0.40s user 0.08s system 68% cpu 0.703 total
xemacs-21.4-2003-11-07-debug
./$d/bin/xemacs -vanilla -kill 0.51s user 0.14s system 74% cpu 0.871 total
xemacs-21.4-2003-11-07-mule
./$d/bin/xemacs -vanilla -kill 0.68s user 0.09s system 74% cpu 1.036 total
xemacs-21.5-2003-11-29-1924
./$d/bin/xemacs -vanilla -kill 0.65s user 0.05s system 82% cpu 0.849 total
xemacs-21.5-2003-11-29-1924-debug
./$d/bin/xemacs -vanilla -kill 0.90s user 0.11s system 84% cpu 1.192 total
xemacs-21.5-2003-11-29-1924-mule
./$d/bin/xemacs -vanilla -kill 2.17s user 0.16s system 93% cpu 2.498 total
Not -vanilla:
xemacs-21.4-2003-11-07
./$d/bin/xemacs -kill 0.93s user 0.12s system 76% cpu 1.377 total
xemacs-21.4-2003-11-07-debug
./$d/bin/xemacs -kill 1.24s user 0.15s system 84% cpu 1.647 total
xemacs-21.4-2003-11-07-mule
./$d/bin/xemacs -kill 1.20s user 0.19s system 86% cpu 1.614 total
xemacs-21.5-2003-11-29-1924
./$d/bin/xemacs -kill 1.25s user 0.13s system 84% cpu 1.634 total
xemacs-21.5-2003-11-29-1924-debug
./$d/bin/xemacs -kill 1.93s user 0.20s system 89% cpu 2.368 total
xemacs-21.5-2003-11-29-1924-mule
./$d/bin/xemacs -kill 3.30s user 0.16s system 91% cpu 3.792 total
These XEmacs are similarly configured between 21.4 and 21.5. It looks
like there's a pretty substantial penalty for running with mule in
21.5.
- Vin
2:32 a.m.
On Mon, 01 Dec 2003 21:06:37 EST, Vin Shelton <acs(a)xemacs.org> said:
xemacs-21.5-2003-11-29-1924
./$d/bin/xemacs -vanilla -kill 0.65s user 0.05s system 82% cpu 0.849 total
xemacs-21.5-2003-11-29-1924-mule
./$d/bin/xemacs -vanilla -kill 2.17s user 0.16s system 93% cpu 2.498 total
So 1.52 seconds extra overhead.
Not -vanilla:
xemacs-21.5-2003-11-29-1924
./$d/bin/xemacs -kill 1.25s user 0.13s system 84% cpu 1.634 total
0.6 seconds more than non-mule -vanilla.
xemacs-21.5-2003-11-29-1924-mule
./$d/bin/xemacs -kill 3.30s user 0.16s system 91% cpu 3.792 total
But here, only 2.05 seconds more overhead - which is almost exactly the same
as the 1.52 seconds overhead for -mule -vanilla plus the 0.6 seconds more that
the non-mule version took as well.....
Looks to me that once MULE gets initialized, its performance isn't that
far out of line - but there's that big 1.52 seconds OINK at startup.
Odd indeed. I'd have expected a much bigger total hit for processing the
non-vanilla version with mule, especially when your init.el is big enough to double the
startup cost. What I'm seeing there is that the CPU costs for processing the init.el
is almost a dead heat to within the /bin/time resolution, the CPU pain is all up-front.
10:44 p.m.
I had a few spare cycles today, so I ran some simple benchmarks on one
of the SunOS-5.8 servers here at work. I ran the attached script to
generate timings for optimized, Mule and debug builds of 21.4 and 21.5
with and without my startup files, running both SunOS-5.5 and
SunOS-5.8 executables.
Here are the timings generated.
./SunOS-5.5/xemacs-21.4-2003-12-01 -vanilla
./xemacs -vanilla -kill 0.30s user 0.07s system 47% cpu 0.780 total
./SunOS-5.5/xemacs-21.4-2003-12-01
./xemacs -kill 0.59s user 0.26s system 61% cpu 1.384 total
./SunOS-5.5/xemacs-21.4-2003-12-01-debug -vanilla
./xemacs -vanilla -kill 0.42s user 0.10s system 61% cpu 0.849 total
./SunOS-5.5/xemacs-21.4-2003-12-01-debug
./xemacs -kill 0.96s user 0.25s system 65% cpu 1.845 total
./SunOS-5.5/xemacs-21.4-2003-12-01-mule -vanilla
./xemacs -vanilla -kill 0.37s user 0.11s system 60% cpu 0.800 total
./SunOS-5.5/xemacs-21.4-2003-12-01-mule
./xemacs -kill 0.75s user 0.20s system 58% cpu 1.634 total
./SunOS-5.5/xemacs-21.5-2003-12-01 -vanilla
./xemacs -vanilla -kill 0.35s user 0.10s system 59% cpu 0.761 total
./SunOS-5.5/xemacs-21.5-2003-12-01
./xemacs -kill 0.76s user 0.22s system 63% cpu 1.555 total
./SunOS-5.5/xemacs-21.5-2003-12-01-debug -vanilla
./xemacs -vanilla -kill 0.65s user 0.15s system 77% cpu 1.036 total
./SunOS-5.5/xemacs-21.5-2003-12-01-debug
./xemacs -kill 1.57s user 0.24s system 76% cpu 2.366 total
./SunOS-5.5/xemacs-21.5-2003-12-01-mule -vanilla
./xemacs -vanilla -kill 1.00s user 0.22s system 77% cpu 1.570 total
./SunOS-5.5/xemacs-21.5-2003-12-01-mule
./xemacs -kill 1.62s user 0.44s system 77% cpu 2.651 total
./SunOS-5.8/xemacs-21.4-2003-12-01 -vanilla
./xemacs -vanilla -kill 0.27s user 0.07s system 59% cpu 0.573 total
./SunOS-5.8/xemacs-21.4-2003-12-01
./xemacs -kill 0.47s user 0.21s system 49% cpu 1.371 total
./SunOS-5.8/xemacs-21.4-2003-12-01-debug -vanilla
./xemacs -vanilla -kill 0.24s user 0.14s system 60% cpu 0.629 total
./SunOS-5.8/xemacs-21.4-2003-12-01-debug
./xemacs -kill 0.65s user 0.22s system 59% cpu 1.456 total
./SunOS-5.8/xemacs-21.4-2003-12-01-mule -vanilla
./xemacs -vanilla -kill 0.31s user 0.13s system 52% cpu 0.832 total
./SunOS-5.8/xemacs-21.4-2003-12-01-mule
./xemacs -kill 0.64s user 0.21s system 52% cpu 1.609 total
./SunOS-5.8/xemacs-21.5-2003-12-01 -vanilla
./xemacs -vanilla -kill 0.28s user 0.16s system 66% cpu 0.667 total
./SunOS-5.8/xemacs-21.5-2003-12-01
./xemacs -kill 0.64s user 0.36s system 66% cpu 1.498 total
./SunOS-5.8/xemacs-21.5-2003-12-01-debug -vanilla
./xemacs -vanilla -kill 0.45s user 0.16s system 76% cpu 0.797 total
./SunOS-5.8/xemacs-21.5-2003-12-01-debug
./xemacs -kill 1.03s user 0.24s system 69% cpu 1.819 total
./SunOS-5.8/xemacs-21.5-2003-12-01-mule -vanilla
./xemacs -vanilla -kill 1.07s user 0.13s system 78% cpu 1.526 total
./SunOS-5.8/xemacs-21.5-2003-12-01-mule
./xemacs -kill 1.60s user 0.31s system 71% cpu 2.670 total
--
In a minute there is time
For decisions and revisions which a minute will reverse. T.S. Eliot
[URL: http://www.cs.amherst.edu/~ccm/prufrock.html]
9:16 a.m.
>>>> "vin" == Vin Shelton <acs(a)xemacs.org>
writes:
vin> These XEmacs are similarly configured between 21.4 and 21.5.
vin> It looks like there's a pretty substantial penalty for
vin> running with mule in 21.5.
Do you explicitly specify error-checking? Off by default in 21.4, on
by default in 21.5, and under Mule error-checking character positions
is O(n) in (point) because the internal encoding is variable-width.
Also, in 21.5 we read in several megabytes of Unicode data at startup,
and we also do a lot more mucking with default fonts IIRC (I think
Mike Sperber reported this). According to a Ben comment, loading
Unicode tables takes "a fraction of a second" on a PIII 700MHz
(whatever that implies about I/O speeds). Lazy-loading is one of
Ben's incomplete projects, but Non-Asian users can probably reduce
that to nil, just by commenting out _never_-used character sets in
lisp/unicode.el (load-unicode-tables).
The font lazy-loading optimization could be put back in (unless Mike
did that already).
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
12:31 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "vin" == Vin Shelton
<acs(a)xemacs.org> writes:
vin> These XEmacs are similarly configured between 21.4 and 21.5.
vin> It looks like there's a pretty substantial penalty for
vin> running with mule in 21.5.
Do you explicitly specify error-checking? Off by default in 21.4, on
by default in 21.5, and under Mule error-checking character positions
is O(n) in (point) because the internal encoding is variable-width.
The non-debug builds (both Mule and non-Mule) are configured
'--with-error-checking=none' and '--with-debug=no'.
- vin
7448
days inactive
7452
days old
9 comments
5 participants
participants (5)
-
Hrvoje Niksic -
Stephen J. Turnbull -
Steve Youngs -
Valdis Kl=?iso8859-4?Q?=BA?=tnieks -
Vin Shelton