GNU bug report logs - #24565
25.1: info freezes on some elements

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24565 in the body.
You can then email your comments to 24565 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1: info freezes on some elements
Date: Thu, 29 Sep 2016 10:30:26 +0300

1. emacs -Q
2. (info "(elisp) Association Lists")
3. Hold down next-line.

What should happen: the moment you see the arrow symbol in some 
examples, you should get a freeze for a couple of seconds. Sexps in the 
beggining of that page, without the arrow do not seem to trigger the 
freeze. It also seems like those freezes are accumulative - that is 
freeze for a page with three arrows is three times as long as a freeze 
for a single arrow.

Happens on Windows.

This bug happens both on master and 25.1, with official binaries. This 
does not happen in 24.5.

-- 
Best Regards,
Nikolay Kudryavtsev

Message #8 received at 24565 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
Cc: 24565 <at> debbugs.gnu.org
Subject: Re: bug#24565: 25.1: info freezes on some elements
Date: Thu, 29 Sep 2016 18:13:13 +0300

> From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
> Date: Thu, 29 Sep 2016 10:30:26 +0300
> 
> 1. emacs -Q
> 2. (info "(elisp) Association Lists")
> 3. Hold down next-line.
> 
> What should happen: the moment you see the arrow symbol in some 
> examples, you should get a freeze for a couple of seconds. Sexps in the 
> beggining of that page, without the arrow do not seem to trigger the 
> freeze. It also seems like those freezes are accumulative - that is 
> freeze for a page with three arrows is three times as long as a freeze 
> for a single arrow.
> 
> Happens on Windows.

Sounds like Emacs is looking for a suitable font to display these
symbols.  That's normal, and happens only once in a session for each
symbol.  I see this on my systems, although the "accumulation" doesn't
happen here: the short delay is independent of the number of identical
symbols on the screenful Emacs is about to display.

> This bug happens both on master and 25.1, with official binaries. This 
> does not happen in 24.5.

Emacs 25.1 changed the font used for these symbols, but otherwise I
see the same delay in Emacs 24.5.

Bottom line, I don't think it's a bug.

Message #11 received at 24565 <at> debbugs.gnu.org (full text, mbox):

From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24565 <at> debbugs.gnu.org
Subject: Re: bug#24565: 25.1: info freezes on some elements
Date: Fri, 30 Sep 2016 13:50:39 +0300

Yes I thought it was font lookup too, but after doing some more testing 
- it does not look like it. Doing next-line or previous line triggers 
it, but page up or page down does not. So the freeze happens when the 
point crosses one of those symbols.

I did some profiling, so here's some data:

Test 1: as described before, but with profiler-start and profiler-report 
when we reach the end of buffer. In 24.5 profiler reports less than 50 
total samples. In 25.1 it reports at least 1900 cpu samples.

Test 2: as test 1, but with down arrow manually pressed every time and 
waiting for cursor to move to the next line. In Emacs 24.5 it takes 50 
seconds to reach the bottom of the buffer and again ~50 samples. But 
with 25.1 it took 2 minutes 34 seconds and at lest 3200 cpu samples.

Test 3: in test 1 I actually let the key go the moment Emacs freezes, 
because every new command adds to the freeze. Now let's do as before, 
but just hold down the down arrow for 30 seconds and see how much it 
takes to unfreeze. Emacs unfroze after 5 minutes and 35 seconds and 
reported ~20000 cpu samples.

Here's a profiler-report structure from test 1:
- command-execute 3664  95%
 - call-interactively 3664  95%
  - funcall-interactively 3615  94%
   - next-line 3614  94%
    - line-move 3614  94%
       line-move-visual 2054  53%
     - line-move-partial 517  13%
      + default-line-height 1   0%
     - window-inside-pixel-edges 3   0%
      - window-edges 3   0%
       - window-current-scroll-bars 3   0%
          frame-current-scroll-bars 3   0%
     - default-line-height 1   0%
        default-font-height 1   0%
   - execute-extended-command 1   0%
    - sit-for 1   0%
       redisplay 1   0%
  - byte-code 49   1%
   - read-extended-command 49   1%
    - completing-read 49   1%
     - completing-read-default 49   1%
      - read-from-minibuffer 45   1%
       - redisplay_internal (C function) 1   0%
        - tool-bar-make-keymap 1   0%
         - tool-bar-make-keymap-1 1   0%
          - mapcar 1   0%
           - #<compiled 0x10011609f>                                1   0%
            - eval 1   0%
             - find-image 1   0%
                image-search-load-path 1   0%
- ... 157   4%

I guess my next task is profiling the с source, is there anything I 
should look into?

-- 
Best Regards,
Nikolay Kudryavtsev

Message #14 received at 24565 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
Cc: 24565 <at> debbugs.gnu.org
Subject: Re: bug#24565: 25.1: info freezes on some elements
Date: Fri, 30 Sep 2016 15:22:20 +0300

> From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
> Cc: 24565 <at> debbugs.gnu.org
> Date: Fri, 30 Sep 2016 13:50:39 +0300
> 
> Here's a profiler-report structure from test 1:
> - command-execute 3664  95%
>   - call-interactively 3664  95%
>    - funcall-interactively 3615  94%
>     - next-line 3614  94%
>      - line-move 3614  94%
>         line-move-visual 2054  53%
>       - line-move-partial 517  13%

If line-move-visual takes the lion's share of the time, then I think
the call to font-info in default-font-height is the prime suspect.  It
happened before: some fonts make that call very expensive, for some
reason.  We did introduce an optimization to alleviate that, but only
when the font in question is the default face's font, which is not
your case.

If my suspicion turns out to be correct, I think the only workaround
(if this problem is annoying enough) is to customize your font setup
to use some other font for these symbols.

Message #17 received at 24565 <at> debbugs.gnu.org (full text, mbox):

From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24565 <at> debbugs.gnu.org
Subject: Re: bug#24565: 25.1: info freezes on some elements
Date: Fri, 30 Sep 2016 18:03:32 +0300

Your theory seems correct. After I changed the font for ⇒, the freezes 
stopped.

In my case the font was Malgun Gothic. Still I don't understand, why 
24.5 works fine, since it's the same Malgun Gothic there too?

Btw, I failed at building Emacs with --enable-profiling. It complains 
about sys/gmon.h. Is it possible on Windows?

If anyone else is having this problem, here's what I did:
You can find the code of a symbol using C-u C-x =, when the point is on 
it. Then you can set a different font for some range of characters:
(set-fontset-font t '(#x21d2 . #x21d2) (font-spec :family "FreeSerif"))

-- 
Best Regards,
Nikolay Kudryavtsev

Message #20 received at 24565 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
Cc: 24565 <at> debbugs.gnu.org
Subject: Re: bug#24565: 25.1: info freezes on some elements
Date: Fri, 30 Sep 2016 19:14:35 +0300

> From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
> Cc: 24565 <at> debbugs.gnu.org
> Date: Fri, 30 Sep 2016 18:03:32 +0300
> 
> Your theory seems correct. After I changed the font for ⇒, the freezes 
> stopped.
> 
> In my case the font was Malgun Gothic. Still I don't understand, why 
> 24.5 works fine, since it's the same Malgun Gothic there too?

I don't know why that happens, the code in default-font-height didn't
change since 24.5, and I don't think font-info changed, either.

> Btw, I failed at building Emacs with --enable-profiling. It complains 
> about sys/gmon.h. Is it possible on Windows?

On Windows, gmon.h is installed in include/, not in include/sys/.  So
I guess we need some trivial source change to DTRT.

Message #23 received at 24565 <at> debbugs.gnu.org (full text, mbox):

From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24565 <at> debbugs.gnu.org
Subject: Re: bug#24565: 25.1: info freezes on some elements
Date: Sat, 1 Oct 2016 11:14:18 +0300

I did some bisecting, traced the offending commit to d5fdffe.

-- 
Best Regards,
Nikolay Kudryavtsev

Message #26 received at 24565 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
Cc: 24565 <at> debbugs.gnu.org
Subject: Re: bug#24565: 25.1: info freezes on some elements
Date: Sat, 01 Oct 2016 11:45:42 +0300

> From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
> Cc: 24565 <at> debbugs.gnu.org
> Date: Sat, 1 Oct 2016 11:14:18 +0300
> 
> I did some bisecting, traced the offending commit to d5fdffe.

Thanks, but I don't see anything wrong with that commit.  Presumably,
the font you used somehow enlarges the font cache too much, so it's
evicted from the cache when GC strikes, and needs to be cached anew
the next time.  IOW, using a different font is TRT in this case.

Message #29 received at 24565 <at> debbugs.gnu.org (full text, mbox):

From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24565 <at> debbugs.gnu.org
Subject: Re: bug#24565: 25.1: info freezes on some elements
Date: Sat, 1 Oct 2016 11:55:44 +0300

That commit removed defines that effectively commented out 
compact_font_cache_entry on Windows, comment there links to #15876, 
which seems to be the original report for this bug.

-- 
Best Regards,
Nikolay Kudryavtsev

Message #32 received at 24565 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
Cc: 24565 <at> debbugs.gnu.org
Subject: Re: bug#24565: 25.1: info freezes on some elements
Date: Sat, 01 Oct 2016 12:17:46 +0300

> From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
> Cc: 24565 <at> debbugs.gnu.org
> Date: Sat, 1 Oct 2016 11:55:44 +0300
> 
> That commit removed defines that effectively commented out 
> compact_font_cache_entry on Windows

Indeed, and on purpose.  That code was ifdef'ed away because it caused
serious problems on Windows that couldn't be resolved for the next
release.  Now they are mostly resolved, so having some code run on
most platforms, but not on Windows, is bad for maintainability.

In particular, not compacting the font cache can potentially bloat the
Emacs memory footprint to humongous proportions, although this only
happens in some rare scenarios.

> comment there links to #15876, which seems to be the original report
> for this bug.

AFAIR, we never got to the bottom of that bug, but perhaps it indeed
has the same reason.

I'm sorry, but none of the active developers here know enough about
font handling in Emacs to fix these issues in a more thorough way.  So
for the time being, if some specific rarely-used font causes
performance degradation, and no simple and safe fix could be found,
the only remedy is to refrain from using that particular font.

Message #35 received at 24565 <at> debbugs.gnu.org (full text, mbox):

From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24565 <at> debbugs.gnu.org
Subject: Re: bug#24565: 25.1: info freezes on some elements
Date: Sat, 1 Oct 2016 12:32:59 +0300

Well, it's rare scenario against another rare scenario. And while font 
bloat is bad when it happens, I feel like this is worse. Emacs is not a 
major memory abuser and I don't think there were many people complaining 
during 24.* when this was commented out. The discussion about #15876 
ended with your suggestion to comment that stuff out just for that bug. 
I think that's still the best solution. But again, your call.

This bug should be closed as a duplicate of 15876.

-- 
Best Regards,
Nikolay Kudryavtsev

Message #38 received at 24565 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
Cc: 24565 <at> debbugs.gnu.org
Subject: Re: bug#24565: 25.1: info freezes on some elements
Date: Sat, 01 Oct 2016 12:48:40 +0300

merge 24565 15876
thanks

> From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
> Cc: 24565 <at> debbugs.gnu.org
> Date: Sat, 1 Oct 2016 12:32:59 +0300
> 
> Well, it's rare scenario against another rare scenario.

The other one is less rare, though.

> And while font bloat is bad when it happens, I feel like this is
> worse.

I don't think I agree.

> The discussion about #15876 ended with your suggestion to comment
> that stuff out just for that bug.

That was before the serious problems I mentioned previously were
fixed.

> This bug should be closed as a duplicate of 15876.

Done.

Thanks.

Message #45 received at 24565-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: nikolay.kudryavtsev <at> gmail.com
Cc: 24565-done <at> debbugs.gnu.org
Subject: Re: bug#24565: 25.1: info freezes on some elements
Date: Sat, 08 Oct 2016 22:37:55 +0300

> Date: Sat, 01 Oct 2016 12:48:40 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 24565 <at> debbugs.gnu.org
> 
> > The discussion about #15876 ended with your suggestion to comment
> > that stuff out just for that bug.
> 
> That was before the serious problems I mentioned previously were
> fixed.

I've now added a variable that can be used to disable the cache
compaction.  See the discussion of bug#24634.

With this, I consider this bug done.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.