[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Performance
From: |
Eli Zaretskii |
Subject: |
Re: Performance |
Date: |
Mon, 07 Jun 2010 09:35:04 -0400 |
> From: Stefan Monnier <address@hidden>
> Date: Sun, 06 Jun 2010 21:05:54 -0400
>
> It seems that functionality-wise, the bidi code is almost as good as it
> was before bidi.
Thanks for testing it.
> But performancewise, I experience some problems.
> I recently started to compile without -DENABLE_CHECKING and other such
> debugging code (tho still with -O0 and -g) and am seeing cases where
> cursor motion is slow. The problem is most notable in operations such
> as C-e or C-n/C-p (tho those tend to be fast enough as long as I'm in
> column 0).
> Redisplay itself also seems to be noticeable slower at times.
I'm a bit surprised, because my main machine is 5 years old, and I
don't see any noticeable slowdown. But then I almost never have 10
frames (let alone more) open at the same time; usually all but 2 are
minimized or iconified.
> This usually shows up after I open a few different buffers&frames (like
> when I have 10 frames or more (each one showing a single file), where
> most frames are sized 80x89).
I will try that (when I'm back from traveling in a few days).
Granted, I didn't yet get to profiling and optimizing the code,
because (a) so many features need yet to get right before I get them
fast, and (b) the current code works reasonably fast for me, even when
I compile with -O0 and even in a buffer with text that really needs
reordering (which I understand is not your case).
>From what you tell, it sounds like vertical cursor motion is the
problem; please try C-f and C-b (_not_ the arrow keys!) and tell if
they are reasonably fast or also slow.
Even if C-f and C-b are fast, I don't immediately see any special
reasons for slowdown with vertical motion, in a buffer with text that
doesn't need reordering, except the code in bidi.c. One way of
testing this hypothesis would be to replace the code in bidi.c with
incrementing it->charpos and it->bytepos, like the unidirectional
iteration does.
Also, what kind of files are those? If it's human-readable text (not
program sources or some such), are paragraphs in it long or short? Do
you see any change in performance if you set bidi-paragraph-direction
to `left-to-right'?
Anyway, I'd love some help in this matter. Getting the bidi code
faster is not a trivial job, but it does not require any knowledge of
bidirectional scripts, and I can help with understanding what the code
does and why. Without someone stepping forward, I doubt that I could
get to seriously working on speeding up the code, what with merely 10
hours a week I have to work on Emacs.
- Performance, Stefan Monnier, 2010/06/06
- Re: Performance,
Eli Zaretskii <=
- arrow keys vs. C-f/b/n/p (was: Performance), David Kastrup, 2010/06/07
- Re: arrow keys vs. C-f/b/n/p (was: Performance), Uday S Reddy, 2010/06/07
- Re: arrow keys vs. C-f/b/n/p, Chong Yidong, 2010/06/11
- Re: arrow keys vs. C-f/b/n/p, Stefan Monnier, 2010/06/11
- RE: arrow keys vs. C-f/b/n/p, Drew Adams, 2010/06/11
- Re: arrow keys vs. C-f/b/n/p, Uday S Reddy, 2010/06/11
- RE: arrow keys vs. C-f/b/n/p, Drew Adams, 2010/06/11