[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Scrolling xdisp.c. Room for optimisation in syntax.c/CC Mode.
From: |
Alan Mackenzie |
Subject: |
Re: Scrolling xdisp.c. Room for optimisation in syntax.c/CC Mode. |
Date: |
Mon, 20 Oct 2014 11:47:27 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hi, Martin.
On Mon, Oct 20, 2014 at 09:29:51AM +0200, martin rudalics wrote:
> Results for Windows XP with CPPFLAGS='-DGLYPH_DEBUG=1' CFLAGS='-O0 -g3'
> --enable-checking=yes --enable-check-lisp-object-type=yes:
> Unmodified xdisp.c from trunk:
> 24.3 1007 scrolls, total time = 105.60900020599365s.
> 24.4 1007 scrolls, total time = 73.21900010108948s.
> 25.0 1007 scrolls, total time = 318.5629997253418s.
> xdisp.c from trunk with odd apostrophes eradicated:
> 24.3 1007 scrolls, total time = 100.1240005493164s.
> 24.4 1007 scrolls, total time = 60.13900017738342s.
> 25.0 1007 scrolls, total time = 197.95300006866455s.
> I can't test with older versions since those don't have
> `scroll-down-command' here.
Just replace it with `scroll-down'.
> So while it might be worthwhile to do such an optimization, here the
> great differenece is the 3-to-5-fold increase of execution time from
> 24.4 to 25.0 for which I don't have an explanation. The cc-mode used is
> always the one bundled with the respective Emacs version.
I got this, until I re-bootstrapped my trunk with full compiler
optimisation, no debugging set, and no extra checks enabled. Then I got
pretty much the same results for the trunk as 24.4.
The main reason I did all this, which nobody's commented on so far, was
to get a handle on how much the `open-paren-in-column-0-is-defun-start',
now bound to nil at critical places in CC Mode, was actually costing on a
large C file. On 24.4 you get 22%, on the trunk, 61%. I get 31% in
24.4, and 32% in the trunk.
It seems that "instrumentation" is increasing the cost of
open-paren-etc.
> martin
> BTW, if you want to quickly visualize constructs like
> (defconst odd-apostrophes
>
> "/\\*\\([^*']\\|\\*+[^*'/]\\)*\\(\\**'\\([^*']\\|\\*+[^*'/]\\)*\\**'\\([^*']\\|\\*+[^*'/]\\)*\\)*\\**\\('\\)\\([^*']\\|\\*+[^*'/]\\)*\\*+/"
> )
> without adding comments like
> ;; 1 2 3 4
> 5 6
> you can use the regexp-lock.el package I attached here ;-)
Neat!
What I actually use is a little tool I wrote called pp-regexp. Given a
string, it dumps a readable representation of the regexp into *scratch*,
something like:
/\*\( \| \)*\(
\)*\**\( \)\( \| \)*\*+/
[^*'] \*+[^*'/] \**'\( \| \)*\**'\( \| \)*
' [^*'] \*+[^*'/]
[^*'] \*+[^*'/] [^*'] \*+[^*'/]
See attached file.
--
Alan Mackenzie (Nuremberg, Germany).
pp-regexp.el.gz
Description: Binary data