From xemacs-m  Sun Feb  9 16:42:13 1997
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5])
	by xemacs.org (8.8.5/8.8.5) with SMTP id QAA16969
	for <xemacs-beta@xemacs.org>; Sun, 9 Feb 1997 16:42:13 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA13394; Sun, 9 Feb 1997 14:41:42 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id OAA10343; Sun, 9 Feb 1997 14:41:40 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA15020; Sun, 9 Feb 1997 14:41:39 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id OAA19401; Sun, 9 Feb 1997 14:41:39 -0800
Date: Sun, 9 Feb 1997 14:41:39 -0800
Message-Id: <199702092241.OAA19401@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
Cc: xemacs-beta@xemacs.org
Subject: Re: wot i need
In-Reply-To: <m2d8uaduc0.fsf@proletcult.slip.ifi.uio.no>
References: <199702091140.AA266538445@martigny.ai.mit.edu>
	<m2d8uaduc0.fsf@proletcult.slip.ifi.uio.no>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.100)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

Lars> Bill Dubuque <wgd@martigny.ai.mit.edu> writes:
>> It would be useful to get more datapoints. If anyone else has
>> XEmacs and FSF compiled on the same machine, please contrast
>> their times on Kyle's original example, which he found twice 
>> as slow in XEmacs:
>> 
>> (let ((i 0)) (while (< i 300000) (setq i (1+ i))))

Lars> I have a 486 running Linux, and I've compared Emacs 19.34 with
Lars> XEmacs 20.0 with Mule using this test:

Lars> (defun make-time-float (list)
Lars>   (+ (* 65536.0 (pop list)) (pop list)
Lars>      (/ (or (pop list) 0) 1e6)))

Lars> (defun time-loop ()
Lars>   (let ((t1 (current-time))
Lars> 	t2)
Lars>     (let ((i 0)) (while (< i 300000) (setq i (1+ i))))
Lars>     (setq t2 (current-time))
Lars>     (- (make-time-float t2)
Lars>        (make-time-float t1))))

Lars> (time-loop)

Lars> And the results are:

Lars> => 29.94636797904968 (XEmacs 20.0 w/Mule)
Lars> => 24.478706955909729 (Emacs 19.34)

I modified Lars' test as follows:
----------------- time-loop.el ----------------------
(require 'cl)

(defun make-time-float (list)
  (+ (* 65536.0 (pop list)) (pop list)
     (/ (or (pop list) 0) 1e6)))

(defun time-loop ()
  (let ((t1 (current-time))
	t2)
    (let ((i 0)) (while (< i 900000) (setq i (1+ i))))
    (setq t2 (current-time))
    (- (make-time-float t2)
       (make-time-float t1))))

(princ (time-loop)) (terpri)

(byte-compile 'make-time-float)
(byte-compile 'time-loop)

(princ (time-loop)) (terpri)
-----------------------------------------------------
and ran it with

./xemacs -batch -l ~/time-loop.el

Results (consistently reproducible to within 1%):

XEmacs/Mule:
7.564292073249817
1.530727028846741

XEmacs/Latin-1:
8.440415978431702
1.488647937774658

Emacs 19.34:
7.0935319662094116
1.3591480255126953

All were compiled with SunPro cc -xO4 and no debugging options.

It's highly bizarre that for XEmacs 20.0, the presence of the Mule
feature makes the interpreted code faster, but the byte-compiled code
slower.  It's well worth understanding the anomaly, and closing the
performance gap, but it's less than 20%, and so one can live with it.

Lars> So this doesn't tally up well with the results Kyle got.  However,
Lars> I am seeing the same massive slowdowns under XEmacs 20.0 that he's
Lars> seing when (for instance) loading .elc files.  When trying to
Lars> reproduce the slowdown by doing simple things (like this timing
Lars> example, or calling functions, or most anything else as simple), I get
Lars> the same results -- XEmacs runs ~20% slower than Emacs, not 100%.

File I/O is slower with Mule.  In general, any external data that must
be converted into `internal representation' (for strings or buffers)
must be examined byte-by-byte for conversion.  Even when using the
'binary coding-system, the internal representation of non-ascii
characters (upper half of iso8859-1) is different from the external
representation.  There used to be lots of code that would put
external filenames into lisp strings without conversion, which was
fast and would cause crashes if the filenames had bytes with the high
bit on.

Reading in .elc files is even worse.  The file contents are read into
a buffer, then they are examined for the magic cookie 

;;;###coding system: 

just to determine coding-system to be used and then loaded for real,
with re-conversion.  So this aspect of (load) is at least twice as
slow in XEmacs/Mule as XEmacs/Latin-1 - twice as much I/O, with
additional coding-system conversion overhead.  There is certainly
scope for optimization of loading .elc files here.  Most .elc files
use the binary coding system, so we can make do with one pass to read
in the .elc file.

(see definition of (load) in mule-files.el)

Martin

