Re: Scrolling xdisp.c. Room for optimisation in syntax.c/CC Mode.

[Alan Mackenzie]

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