bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9008: 23.2; Sluggishness when editing large latex files containing C


From: Eli Zaretskii
Subject: bug#9008: 23.2; Sluggishness when editing large latex files containing CJK text using preview-latex, due to slow buf_bytepos_to_charpos
Date: Sun, 22 Jun 2014 19:44:47 +0300

> From: r6144 <rainy6144@gmail.com>
> Date: Wed, 06 Jul 2011 21:00:53 +0800
> 
> I'm using auctex to edit a large latex file (about 400kB in size)
> containing Chinese text as well as about 6000 equations previewed with
> preview-latex.  Emacs feels a bit sluggish in this mode: individual
> cursor movements are not delayed much, but when holding down the right
> arrow key, the cursor does not keep moving but only shows up in the new
> position after I release the key, while fill-paragraph can take more
> than a second.  The CPU usage is high during these operations, even
> though I have a modern Core 2 Quad CPU.

Do you still see this problem with the current Emacs?

> According to oprofile, the top consumer of CPU time is
> buf_bytepos_to_charpos() within the loop over all the markers.  Indeed,
> it seems that each preview image (which is an Emacs overlay) has two
> markers at respectively its beginning and its end, so the total number
> of markers in that buffer, according to
> 
> (with-current-buffer MY-BUFFER
>   (loop for i from (point-min) to (point-max) count
> (buffer-has-markers-at i)))
> 
> is 12856.  As buf_bytepos_to_charpos() seems to be called via the
> BYTE_TO_CHAR() macro from many places, the sluggishness is well
> expected.
> 
> Although having such a large number of markers slows down other
> operations as well, they seem necessary when so many preview images are
> present.  In any case, buf_bytepos_to_charpos() seems to be the most
> important one, as operations on another English latex file with a
> similar number of preview images is far less sluggish
> (buf_bytepos_to_charpos() returns early when there are no multibyte
> characters).
> 
> I guess the markers should be organized in something other than a linked
> list.  Maybe a balanced binary tree ordered by position, with each node
> storing the bytepos and charpos offsets compared to its parent?  In this
> way lookups as well as insertions/deletions should be fast enough.

If the problem still exists, I'm not sure what we can do with it.
preview-latex is not part of Emacs, and none of its maintainers
commented on this report.  If indeed buf_bytepos_to_charpos is the
hotspot (and it's hard to say, given that oprofile's report was not
posted), then I see nothing surprising in that fact, since this
function is heavily used when accessing a buffer with lots of
non-ASCII characters.  If preview-latex is not scalable enough in such
buffers, then I suggest to take this issue up with AUCTeX developers
first.  If they analyze the issue and conclude that there's something
wrong with related Emacs primitives, let them come back with more
information.

At this point I can only say that buf_bytepos_to_charpos is as
optimized as we could reasonably make it.

In general, any application that uses many overlays will scale badly
in the current Emacs.  But that doesn't mean we need a separate bug
report about each such application.

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]