6:08 p.m.
Hi,
With this version of XEmacs on Windows (native), I am seeing slowdown in
basic cursor movement functions (C-f, C-b, C-n, C-p). Is there any
possibility that this is due to the syntax-table patches for Windows ?
-kitty.
--
Krishnakumar B <kitty at cs dot wustl dot edu>
Distributed Object Computing Laboratory, Washington University in St.Louis
7:02 p.m.
At 12:08 PM 9/4/2002 -0500, Krishnakumar B wrote:
With this version of XEmacs on Windows (native), I am seeing slowdown
in
basic cursor movement functions (C-f, C-b, C-n, C-p). Is there any
possibility that this is due to the syntax-table patches for Windows ?
Interesting, exactly the opposite is supposed to occur. Yes - only the
syntax changes can be responsible. What kind of file are you editing?
andy
8:45 p.m.
On Wednesday, 4 September 2002, Andy Piper wrote:
At 12:08 PM 9/4/2002 -0500, Krishnakumar B wrote:
>With this version of XEmacs on Windows (native), I am seeing slowdown in
>basic cursor movement functions (C-f, C-b, C-n, C-p). Is there any
>possibility that this is due to the syntax-table patches for Windows ?
Interesting, exactly the opposite is supposed to occur. Yes - only the
syntax changes can be responsible. What kind of file are you editing?
C++ files with maximum syntax highlighting (if that matters). Sometimes the
files are large. The reason I noticed was that I frequently mark regions
using the keyboard and marking a big function suddely became very slow as
if I had turned off autorepeat and was pressing the key repeatedly.
-kitty.
--
Krishnakumar B <kitty at cs dot wustl dot edu>
Distributed Object Computing Laboratory, Washington University in St.Louis
8:50 p.m.
At 02:45 PM 9/4/2002 -0500, Krishnakumar B wrote:
C++ files with maximum syntax highlighting (if that matters).
Sometimes the
files are large. The reason I noticed was that I frequently mark regions
using the keyboard and marking a big function suddely became very slow as
if I had turned off autorepeat and was pressing the key repeatedly.
*sigh* oh dear. Maybe I will have to revert the change. I have exactly the
opposite experience with large java files.
andy
2:12 a.m.
>>>> "Andy" == Andy Piper
<andyp(a)san-francisco.bea.com> writes:
Andy> *sigh* oh dear. Maybe I will have to revert the change.
I think you should. We have a crash report, we have performance
problems being reported, we have a known reversion of a patch that Ben
said prevents crashes, and we have _many_ reversions that have at best
unclear connection to syntax-table text properties, some of which look
like they are bug-fixes for things like infloops and not advancing
pointers and things like that.
Andy> I have exactly the opposite experience with large java
Andy> files.
This is not surprising; semantic exercises all of the relevent
functionality hard, and JDE provides more intrusive^Wsupportive
functionality than pretty much any other mode.
In the meantime I've reduced your patch to about half its original
size. I think I can halve it again, at which point it should be
pretty obvious where to start looking for "Matt's molasses".
One interesting fact that has been identified already is that Matt
substituted parse-partial-sexp for syntactically-sectionalize in the
core font-lock function dealing with syntactic fontification.
Interestingly enough, syntactically-sectionalize has _no_
update_syntax_cache code in it. Why don't you revert your patch and
just reapply the font-lock.el portion, and see what happens to JDE
performance?
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
2:39 a.m.
At 10:12 AM 9/5/2002 +0900, Stephen J. Turnbull wrote:
>>>>> "Andy" == Andy Piper
<andyp(a)san-francisco.bea.com> writes:
Andy> *sigh* oh dear. Maybe I will have to revert the change.
I think you should. We have a crash report, we have performance
problems being reported, we have a known reversion of a patch that Ben
Actually it turns out the performance problem is unrelated (to even XEmacs)
and the crash is unrelated also.
said prevents crashes, and we have _many_ reversions that have at best
The Ben thing I will fix.
In the meantime I've reduced your patch to about half its
original
size. I think I can halve it again, at which point it should be
pretty obvious where to start looking for "Matt's molasses".
That's cool. If that's the only good thing I have provoked that's still cool.
One interesting fact that has been identified already is that Matt
substituted parse-partial-sexp for syntactically-sectionalize in the
core font-lock function dealing with syntactic fontification.
Interestingly enough, syntactically-sectionalize has _no_
update_syntax_cache code in it. Why don't you revert your patch and
just reapply the font-lock.el portion, and see what happens to JDE
performance?
font-lock has very little to do with it. Turning off font-lock entirely
still does not make any appreciable difference to indentation slowness
(maybe it shaved a second off the 15, I don't know). I didn't see much
difference in font-lock performance with or without matt's patch, the only
reason I included it was because I don't have time to come up with a proper
patch and messing with it is a sure route to disaster.
andy
2:55 a.m.
On Wednesday, 4 September 2002, Andy Piper wrote:
At 10:12 AM 9/5/2002 +0900, Stephen J. Turnbull wrote:
> >>>>> "Andy" == Andy Piper
<andyp(a)san-francisco.bea.com> writes:
>
> Andy> *sigh* oh dear. Maybe I will have to revert the change.
>
>I think you should. We have a crash report, we have performance
>problems being reported, we have a known reversion of a patch that Ben
Actually it turns out the performance problem is unrelated (to even XEmacs)
and the crash is unrelated also.
Performance problem with your patch may be unrelated but there is some
problem with XEmacs and font-lock with big files. XEmacs 21.5 was a bit
better with lazy-lock but other changes to 21.5 have resulted in simple
things like manual-entry filling up my buffer with ^H^H all over, typing
M-x manual-entry from scratch it deletes the top line in scratch and puts
scratch in Manual mode and other weird things, that I am not able to use it
like I used to anymore.
I was hoping that your patch will restore atleast 21.4 to the same level as
20.4 but it's been a while since I used 20.4 or even 21.1 so all I can say
at the moment is that it is slow.
Hopefully 21.5 will get usable so that I can go back to using it, if there
are fundamental problems with 21.4 which are not worth backporting from
21.5.
-kitty.
--
Krishnakumar B <kitty at cs dot wustl dot edu>
Distributed Object Computing Laboratory, Washington University in St.Louis
3:52 a.m.
New subject: Slow cursor movements with XEmacs 21.4.9 "Informed Management (Windows [2])"
Performance problem with your patch may be unrelated but there is
some
problem with XEmacs and font-lock with big files. XEmacs 21.5 was a bit
You mean font-lock is too slow? Do you have some sort of comparison?
andy
4:35 a.m.
New subject: Slow cursor movements with XEmacs 21.4.9 "Informed Management (Windows [2])"
On Wednesday, 4 September 2002, Andy Piper wrote:
> Performance problem with your patch may be unrelated but there
is some
> problem with XEmacs and font-lock with big files. XEmacs 21.5 was a bit
You mean font-lock is too slow?
Yes.
Do you have some sort of comparison?
What kind of comparisons do you need ? I mean between different minor
versions or with something else like GNU Emacs ?
-kitty.
--
Krishnakumar B <kitty at cs dot wustl dot edu>
Distributed Object Computing Laboratory, Washington University in St.Louis
8114
days inactive
8115
days old
8 comments
4 participants
participants (4)
-
Andy Piper -
Andy Piper -
Krishnakumar B -
Stephen J. Turnbull