From: Eli Zaretskii <eliz@gnu.org>
To: Sebastien Vauban <sva-news@mygooglest.com>,
Dmitry Antipov <dmantipov@yandex.ru>
Cc: 15876@debbugs.gnu.org
Subject: bug#15876: 24.3.50; Highly degraded performance between rev 114715 and 115006
Date: Sun, 01 Dec 2013 18:31:51 +0200 [thread overview]
Message-ID: <83haas5y88.fsf@gnu.org> (raw)
In-Reply-To: <867gbqdisp.fsf@somewhere.org>
> From: "Sebastien Vauban" <sva-news@mygooglest.com>
> Cc: 15876@debbugs.gnu.org
> Date: Fri, 29 Nov 2013 22:01:10 +0100
>
> Eli Zaretskii wrote:
> >> From: "Sebastien Vauban" <sva-news@mygooglest.com>
> >> Cc: 15876@debbugs.gnu.org
> >> Date: Tue, 26 Nov 2013 21:52:05 +0100
> >>
> >> > So what is the minimum .emacs that will cause the problem?
> >>
> >> That does it:
> >>
> >> --8<---------------cut here---------------start------------->8---
> >> ;; highlight trailing whitespaces in all modes
> >> (setq-default show-trailing-whitespace t)
> >>
> >> (setq org-ellipsis " \u25B7") ; string
> >> --8<---------------cut here---------------end--------------->8---
> >
> > And this makes Emacs slow in scrolling for any file you visit? Or
> > just in Org buffers?
>
> No problem, with the same files, if I put them in `text-mode'. So, it becomes
> apparent with Org.
>
> Remember I told there were similar speed problems with some Gnus buffer, but I
> haven't tested them again.
>
> > If the latter, perhaps your Org files are special in some way, because
> > the ones I tried don't show any slowdown I could sense.
>
> They aren't special, for two reasons:
>
> - They're not mine; they're public Org files taken from the Worg project ("Wiki
> Org").
>
> - They work perfectly in Emacs rev 114715: no performance degradation
> whatsoever.
>
> For the sake of clarity, I've redone a comparison of the two different Emacs
> (r114715 and the recent r115235) on the same two Org files:
>
> - ChangeLog.org (1,156 bytes)
> http://code.ohloh.net/file?fid=s6NzuuiKK0Nlga9EF-Vh8KzVXiw&cid=SNfK_pTfQmo&s=&fp=19410&mp=&projSelected=true#L0
>
> - org-faq.org (164,174 bytes)
> http://code.ohloh.net/file?fid=Jk4U4mwQtJT_5LfYpl3sBLhj42s&cid=SNfK_pTfQmo&s=&fp=19410&mp=&projSelected=true#L0
I looked at this issue.
It has nothing to do with org-ellipsis, or the Org mode in general.
To reproduce it, it's enough to do just this:
emacs -Q
C-x 8 RET 25b7 RET
Now try moving the cursor across the line that displays the triangle
character u+25B7. If you are on Windows 7, this will use the
BatangChe font for the triangle, and every redisplay operation, even
cursor motion, will be extremely slow. (On XP, this font is not
installed, and even if I install it, I'm unable to trigger the same
problem, for some reason.)
This slowdown seems to be caused by this commit:
revno: 114735
committer: Dmitry Antipov <dmantipov@yandex.ru>
branch nick: trunk
timestamp: Mon 2013-10-21 14:11:25 +0000
message:
Do not allow font caches to grow too large.
* alloc.c (compact_font_cache_entry, compact_font_caches):
New functions or stub if not HAVE_WINDOW_SYSTEM.
(compact_undo_list): Factor out from Fgarbage_collect.
Add comment.
(mark_face_cache): Mark face font. Move down to avoid
extra prototypes.
(mark_terminals): Do not mark font cache here.
(Fgarbage_collect): Call compaction functions described
above. Adjust comment.
What happens is that the above-mentioned font causes a lot of consing,
when loaded (perhaps because it supports many different Unicode
blocks). That triggers GC immediately after redisplay; GC calls
compact_font_caches, which for some reason decides that the font-specs
in the font cache can be removed. Then the next redisplay needs the
deleted font again, so it again loads it, which causes consing, which
triggers GC, etc. etc.
If I disable the compacting, like this:
static void
compact_font_caches (void)
{
struct terminal *t;
for (t = terminal_list; t; t = t->next_terminal)
{
Lisp_Object cache = TERMINAL_FONT_CACHE (t);
#if 0
if (CONSP (cache))
{
Lisp_Object entry;
for (entry = XCDR (cache); CONSP (entry); entry = XCDR (entry))
XSETCAR (entry, compact_font_cache_entry (XCAR (entry)));
}
#endif
mark_object (cache);
}
}
then the problem goes away.
Dmitry, can you please look into this? I'm not familiar enough with
the font stuff, so I don't see how was the font-spec and its
font-entities stored in the font cache supposed to be referenced from
some other Lisp object, to make sure they are marked and not GC'ed.
In any case, it seems like they are never marked on Windows, because
if I set a breakpoint in the line marked below:
/* If font-spec is not marked, most likely all font-entities
are not marked too. But we must be sure that nothing is
marked within OBJ before we really drop it. */
for (i = 0; i < size; i++)
if (VECTOR_MARKED_P (XFONT_ENTITY (AREF (XCDR (obj), i))))
break;
if (i == size) <<<<<<<<<<<<<<<<<<<<<
drop = 1;
}
with a condition i != size, that breakpoint never breaks. If you see
something different on X, please tell which code is responsible for
marking those font-entities and/or the font-spec's in the font cache.
(I guess you meant mark_face_cache to do that, but it marks fonts, not
font-entities or font-spec's.)
next prev parent reply other threads:[~2013-12-01 16:31 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-12 15:32 bug#15876: 24.3.50; Highly degraded performance between rev 114715 and 115006 Sebastien Vauban
2013-11-12 17:11 ` Glenn Morris
[not found] ` <wzwqkdfsts.fsf-iW7gFb+/I3LZHJUXO5efmti2O/JbrIOy@public.gmane.org>
2013-11-12 19:13 ` Sebastien Vauban
2013-11-13 11:43 ` Dani Moncayo
[not found] ` <mailman.5954.1384343055.10748.bug-gnu-emacs@gnu.org>
2013-11-13 13:58 ` Sebastien Vauban
[not found] ` <mailman.5925.1384283656.10748.bug-gnu-emacs@gnu.org>
[not found] ` <mailman.5925.1384283656.10748.bug-gnu-emacs-mXXj517/zsQ@public.gmane.org>
2013-11-13 14:04 ` Sebastien Vauban
2013-11-13 16:11 ` Eli Zaretskii
[not found] ` <83fvr01du4.fsf-mXXj517/zsQ@public.gmane.org>
2013-11-13 20:23 ` Sebastien Vauban
2013-11-13 20:35 ` Eli Zaretskii
2013-11-14 3:05 ` Glenn Morris
[not found] ` <jxeh6j1y4x.fsf-iW7gFb+/I3LZHJUXO5efmti2O/JbrIOy@public.gmane.org>
2013-11-14 10:05 ` Sebastien Vauban
[not found] ` <mailman.6048.1384423574.10748.bug-gnu-emacs@gnu.org>
2013-11-14 10:13 ` Sebastien Vauban
2013-11-14 17:04 ` Glenn Morris
[not found] ` <mailman.6048.1384423574.10748.bug-gnu-emacs-mXXj517/zsQ@public.gmane.org>
2013-11-19 22:52 ` Sebastien Vauban
2013-11-20 1:47 ` Stefan Monnier
2013-11-20 3:53 ` Eli Zaretskii
2013-11-20 3:48 ` Eli Zaretskii
[not found] ` <mailman.6579.1384912163.10748.bug-gnu-emacs@gnu.org>
[not found] ` <mailman.6579.1384912163.10748.bug-gnu-emacs-mXXj517/zsQ@public.gmane.org>
2013-11-20 8:48 ` Sebastien Vauban
[not found] ` <mailman.6575.1384901595.10748.bug-gnu-emacs@gnu.org>
[not found] ` <mailman.6575.1384901595.10748.bug-gnu-emacs-mXXj517/zsQ@public.gmane.org>
2013-11-20 22:32 ` Sebastien Vauban
2013-11-21 3:42 ` Eli Zaretskii
[not found] ` <mailman.6739.1385005456.10748.bug-gnu-emacs@gnu.org>
[not found] ` <mailman.6739.1385005456.10748.bug-gnu-emacs-mXXj517/zsQ@public.gmane.org>
2013-11-26 20:52 ` Sebastien Vauban
2013-11-26 21:04 ` Eli Zaretskii
[not found] ` <mailman.7212.1385499914.10748.bug-gnu-emacs@gnu.org>
[not found] ` <mailman.7212.1385499914.10748.bug-gnu-emacs-mXXj517/zsQ@public.gmane.org>
2013-11-29 21:01 ` Sebastien Vauban
2013-12-01 16:31 ` Eli Zaretskii [this message]
2013-12-02 10:45 ` Dmitry Antipov
2013-12-02 11:43 ` Dmitry Antipov
2013-12-02 18:00 ` Eli Zaretskii
2013-12-02 17:52 ` Eli Zaretskii
2013-12-03 9:57 ` Dmitry Antipov
2013-12-03 13:16 ` Eli Zaretskii
2013-12-03 15:09 ` Dmitry Antipov
2013-12-04 17:53 ` Eli Zaretskii
2013-12-05 6:29 ` Dmitry Antipov
2013-12-05 17:36 ` Eli Zaretskii
2013-12-11 6:52 ` Dmitry Antipov
2013-12-11 7:16 ` bug#15876: [SPAM] " Jarek Czekalski
2013-12-11 9:24 ` Dmitry Antipov
2013-12-11 16:28 ` Eli Zaretskii
2013-12-11 18:00 ` Dmitry Antipov
2013-12-11 18:12 ` Eli Zaretskii
2013-12-11 19:50 ` Jan Djärv
2013-12-13 15:22 ` Eli Zaretskii
2013-12-13 16:12 ` Dmitry Antipov
2013-12-13 16:45 ` Stefan Monnier
2013-12-13 18:53 ` Eli Zaretskii
2013-12-13 18:44 ` Eli Zaretskii
2013-12-16 8:05 ` Dmitry Antipov
2013-12-13 16:50 ` Stefan Monnier
2013-12-13 18:55 ` Eli Zaretskii
2013-12-14 2:13 ` Stefan Monnier
2013-12-14 8:47 ` Jan Djärv
[not found] ` <mailman.7746.1385915595.10748.bug-gnu-emacs@gnu.org>
[not found] ` <mailman.7746.1385915595.10748.bug-gnu-emacs-mXXj517/zsQ@public.gmane.org>
2013-12-01 20:20 ` Sebastien Vauban
2013-12-01 20:37 ` Eli Zaretskii
[not found] ` <mailman.7763.1385930292.10748.bug-gnu-emacs@gnu.org>
[not found] ` <mailman.7763.1385930292.10748.bug-gnu-emacs-mXXj517/zsQ@public.gmane.org>
2013-12-01 21:51 ` Sebastien Vauban
2013-12-02 3:45 ` Eli Zaretskii
[not found] ` <mailman.7786.1385955973.10748.bug-gnu-emacs@gnu.org>
[not found] ` <mailman.7786.1385955973.10748.bug-gnu-emacs-mXXj517/zsQ@public.gmane.org>
2013-12-02 9:29 ` Sebastien Vauban
2013-11-13 16:52 ` Stefan Monnier
2013-11-14 11:03 ` Jarek Czekalski
2013-11-14 16:35 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83haas5y88.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=15876@debbugs.gnu.org \
--cc=dmantipov@yandex.ru \
--cc=sva-news@mygooglest.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.