From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Lars Magne Ingebrigtsen <larsi@gnus.org>
Cc: emacs-devel@gnu.org
Subject: Re: Compiling Elisp to a native code with a GCC plugin
Date: Sat, 18 Sep 2010 02:40:20 +0900 [thread overview]
Message-ID: <87mxrgxo8r.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <m3r5gsldnp.fsf@quimbies.gnus.org>
Lars Magne Ingebrigtsen writes:
> I think that's a rather ... stunning approach, but might explain
> many things about XEmacs.
I rather suspect it does. ;-)
> I've presented a use case, and I've demonstrated how all the
> alternative implementations are 50-150% slower than my suggested
> new implementation, and I've done the implementation, which turned
> out to be totally trivial.
Nothing that deals with Emacs strings or buffers is totally trivial,
as a general principle.
Then, again, it looks like David has discovered at least one bug
(texts with different values of multibyteness), maybe more (bounds
checking and integral type confusion), in your "totally trivial"
implementation already.
> What more do you need?
First, I'm curious which machine and what data (buffer) you're using
that took 9 seconds to run that benchmark. When I ran the benchmark
(environment described below) using XEmacs on a 1.8MHz Opteron machine
(quad core, but XEmacs can't take advantage of it) I discovered that
10,000 iterations takes ~300ms uncompiled, ~200ms compiled, and ~150ms
compiled and with the call to `search-forward' in question replaced
with a call to `ignore'. I don't see a win here unless you're really
calling that function 10,000 times or more, and in a very tight loop.
So, is it really Gnus's habit to execute that form 10,000 times in a
loop so that its execution time dominates the user's perceived lag
time? I bet that most uses involve parsing 20-40 RFC 822-style
headers, and the rest parse lines lazily. If so, even the reported 9
second benchmark really amounts to a total of 50-100ms, which is less
than the "just noticable difference" for a fast human.
***** You can stop reading unless you really want to know the details. *****
Specifically, profiling 10000 iterations in a 997-byte buffer
containing three instances of "^(defun " (none at BOB) returned almost
faster than I can detect (288ms), based on
(defun is-the-string-following-point-equal-to-this-string-p (s)
(search-forward s (+ (point) (length s)) t))
(defun test ()
(while (or (is-the-string-following-point-equal-to-this-string-p "(defun ")
(search-forward "\n(defun " nil t))
(forward-line 1)))
(profile-expression '(let ((i 10000))
(while (> i 0)
(goto-char (point-min))
(test)
(setq i (1- i)))))
giving the profiling results below (note, all functions defined above
are *uncompiled*). (Note that the total in the Ticks column may not
be the sum of the Ticks; this apparently has to do with reentering the
profiler and Ben didn't think it was worth fixing it.)
Function Name Ticks/Total %Usage Calls GC-Usage/ Total
========================/===== ====== ===== ========/=======
search-forward 121/ 121 42.160 80000
(profile overhead) 101/ 101 35.192
is-the-string-following-point-equal-to-this-string-p
24/ 129 8.362 40000
while 11/ 288 3.833 10001
or 8/ 231 2.787 40000
+ 6/ 6 2.091 40000
forward-line 5/ 5 1.742 30000
setq 5/ 6 1.742 10000
point 2/ 2 0.697 40000
test 2/ 262 0.697 10000
length 1/ 1 0.348 40000
> 1/ 1 0.348 10001
let 0/ 288 0.000 1
point-min 0/ 0 0.000 10000
1- 0/ 0 0.000 10000
goto-char 0/ 0 0.000 10000
------------------------------------------------------------
Total 288 100.000 380005 0
Ticks/Total = Ticks this function/this function and descendants
Calls = Number of calls to this function
GC-Usage/Total = Lisp allocation this function/this function and descendants
One tick = 1 ms
Compiled (including the profiling expression, that's `test1'), the
result is
Function Name Ticks/Total %Usage Calls GC-Usage/ Total
========================/===== ====== ===== ========/=======
search-forward 112/ 112 59.574 80000
(profile overhead) 42/ 42 22.340
is-the-string-following-point-equal-to-this-string-p
16/ 85 8.511 40000
test 13/ 181 6.915 10000
test1 5/ 190 2.660 1
------------------------------------------------------------
Total 190 100.000 130003 0
Ticks/Total = Ticks this function/this function and descendants
Calls = Number of calls to this function
GC-Usage/Total = Lisp allocation this function/this function and descendants
One tick = 1 ms
And here's the result with the search-forward in the predicate
replaced with ignore (which apparently conses because of the &rest
argument, and I'm not sure why the number is so huge):
Function Name Ticks/Total %Usage Calls GC-Usage/ Total
========================/===== ====== ===== ========/=======
search-forward 74/ 74 44.578 40000
(profile overhead) 32/ 32 19.277
test 24/ 158 14.458 10000 0/3840000
ignore 19/ 22 11.446 40000 3840000/3840000
is-the-string-following-point-equal-to-this-string-p
11/ 46 6.627 40000 0/3840000
test1 6/ 166 3.614 1 0/3840000
------------------------------------------------------------
Total 0 100.000 130003 3840000
Ticks/Total = Ticks this function/this function and descendants
Calls = Number of calls to this function
GC-Usage/Total = Lisp allocation this function/this function and descendants
One tick = 1 ms
next prev parent reply other threads:[~2010-09-17 17:40 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-14 19:12 Compiling Elisp to a native code with a GCC plugin Wojciech Meyer
2010-09-14 19:32 ` Tom Tromey
2010-09-14 19:45 ` Wojciech Meyer
2010-09-14 20:17 ` Lars Magne Ingebrigtsen
2010-09-14 20:52 ` Wojciech Meyer
2010-09-14 20:55 ` Tom Tromey
2010-09-14 21:05 ` Wojciech Meyer
2010-09-14 20:44 ` Tom Tromey
2010-09-14 21:00 ` Wojciech Meyer
2010-09-14 21:16 ` Tom Tromey
2010-09-14 21:29 ` Wojciech Meyer
2010-09-14 21:59 ` Tom Tromey
2010-09-14 22:37 ` Wojciech Meyer
2010-09-14 22:55 ` Tom Tromey
2010-09-14 23:33 ` Wojciech Meyer
2010-09-15 1:38 ` Tom Tromey
2010-09-14 22:49 ` Wojciech Meyer
2010-09-14 23:13 ` Thomas Lord
2010-09-14 23:42 ` Wojciech Meyer
2010-09-15 10:47 ` Leo
2010-09-15 11:41 ` Andreas Schwab
2010-09-15 12:10 ` Wojciech Meyer
2010-09-15 14:07 ` Stefan Monnier
2010-09-15 14:27 ` Helmut Eller
2010-09-15 14:59 ` Stefan Monnier
2010-09-15 15:09 ` Lars Magne Ingebrigtsen
2010-09-15 15:31 ` Andreas Schwab
2010-09-15 15:35 ` Lars Magne Ingebrigtsen
2010-09-15 16:28 ` Andreas Schwab
2010-09-16 16:57 ` Lars Magne Ingebrigtsen
2010-09-15 15:42 ` Stefan Monnier
2010-09-15 15:51 ` Lars Magne Ingebrigtsen
2010-09-15 15:57 ` Leo
2010-09-15 16:01 ` Lars Magne Ingebrigtsen
2010-09-15 16:05 ` David Kastrup
2010-09-15 16:23 ` Leo
2010-09-15 16:37 ` David Kastrup
2010-09-16 16:58 ` Lars Magne Ingebrigtsen
2010-09-16 21:11 ` Andreas Schwab
2010-09-16 23:17 ` Lars Magne Ingebrigtsen
2010-09-17 8:13 ` Eli Zaretskii
2010-09-17 13:17 ` Lars Magne Ingebrigtsen
2010-09-17 13:30 ` Eli Zaretskii
2010-09-17 13:34 ` Lars Magne Ingebrigtsen
2010-09-16 17:35 ` Lars Magne Ingebrigtsen
2010-09-16 2:57 ` Stephen J. Turnbull
2010-09-16 6:54 ` David Kastrup
2010-09-16 8:10 ` Stephen J. Turnbull
2010-09-16 8:31 ` David Kastrup
2010-09-16 17:01 ` Lars Magne Ingebrigtsen
2010-09-17 6:52 ` Stephen J. Turnbull
2010-09-17 13:09 ` Lars Magne Ingebrigtsen
2010-09-17 13:31 ` David Kastrup
2010-09-17 13:39 ` Lars Magne Ingebrigtsen
2010-09-17 13:55 ` David Kastrup
2010-09-17 14:18 ` Lars Magne Ingebrigtsen
2010-09-17 14:57 ` David Kastrup
2010-09-17 15:06 ` Lars Magne Ingebrigtsen
2010-09-17 15:24 ` Lars Magne Ingebrigtsen
2010-09-17 16:11 ` Eli Zaretskii
2010-09-17 16:33 ` David Kastrup
2010-09-17 16:41 ` Andreas Schwab
2010-09-17 17:17 ` David Kastrup
2010-09-17 18:24 ` David Kastrup
2010-09-17 20:30 ` David Kastrup
2010-09-17 20:49 ` Lars Magne Ingebrigtsen
2010-09-18 4:31 ` David Kastrup
2010-09-17 18:53 ` Stephen J. Turnbull
2010-09-17 20:57 ` Eli Zaretskii
2010-09-18 14:19 ` Stephen J. Turnbull
2010-09-18 15:46 ` Eli Zaretskii
2010-09-18 15:58 ` Stefan Monnier
2010-09-17 17:24 ` Lars Magne Ingebrigtsen
2010-09-17 16:11 ` David Kastrup
2010-09-17 16:18 ` Eli Zaretskii
2010-09-17 16:24 ` Lars Magne Ingebrigtsen
2010-09-17 16:39 ` Eli Zaretskii
2010-09-17 17:30 ` Lars Magne Ingebrigtsen
2010-09-17 18:49 ` Eli Zaretskii
2010-09-17 16:39 ` Eli Zaretskii
2010-09-17 13:49 ` Andreas Schwab
2010-09-17 13:55 ` Lars Magne Ingebrigtsen
2010-09-17 14:31 ` Wojciech Meyer
2010-09-17 14:40 ` Andreas Schwab
2010-09-17 14:47 ` Lars Magne Ingebrigtsen
2010-09-17 15:10 ` Andreas Schwab
2010-09-17 15:16 ` Lars Magne Ingebrigtsen
2010-09-17 15:39 ` Andreas Schwab
2010-09-17 15:42 ` Lars Magne Ingebrigtsen
2010-09-17 16:04 ` Andreas Schwab
2010-09-17 16:14 ` Eli Zaretskii
2010-09-17 19:22 ` James Cloos
2010-09-17 17:40 ` Stephen J. Turnbull [this message]
2010-09-17 19:40 ` Lars Magne Ingebrigtsen
2010-09-15 15:46 ` Helmut Eller
2010-09-15 16:28 ` Thomas Lord
2010-09-15 21:04 ` Leo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mxrgxo8r.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=emacs-devel@gnu.org \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.