* bug#24565: 25.1: info freezes on some elements
@ 2016-09-29 7:30 Nikolay Kudryavtsev
2016-09-29 15:13 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Nikolay Kudryavtsev @ 2016-09-29 7:30 UTC (permalink / raw)
To: 24565
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24565: 25.1: info freezes on some elements
2016-09-29 7:30 bug#24565: 25.1: info freezes on some elements Nikolay Kudryavtsev
@ 2016-09-29 15:13 ` Eli Zaretskii
2016-09-30 10:50 ` Nikolay Kudryavtsev
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2016-09-29 15:13 UTC (permalink / raw)
To: Nikolay Kudryavtsev; +Cc: 24565
> From: Nikolay Kudryavtsev <nikolay.kudryavtsev@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24565: 25.1: info freezes on some elements
2016-09-29 15:13 ` Eli Zaretskii
@ 2016-09-30 10:50 ` Nikolay Kudryavtsev
2016-09-30 12:22 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Nikolay Kudryavtsev @ 2016-09-30 10:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 24565
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24565: 25.1: info freezes on some elements
2016-09-30 10:50 ` Nikolay Kudryavtsev
@ 2016-09-30 12:22 ` Eli Zaretskii
2016-09-30 15:03 ` Nikolay Kudryavtsev
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2016-09-30 12:22 UTC (permalink / raw)
To: Nikolay Kudryavtsev; +Cc: 24565
> From: Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>
> Cc: 24565@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24565: 25.1: info freezes on some elements
2016-09-30 12:22 ` Eli Zaretskii
@ 2016-09-30 15:03 ` Nikolay Kudryavtsev
2016-09-30 16:14 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Nikolay Kudryavtsev @ 2016-09-30 15:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 24565
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24565: 25.1: info freezes on some elements
2016-09-30 15:03 ` Nikolay Kudryavtsev
@ 2016-09-30 16:14 ` Eli Zaretskii
2016-10-01 8:14 ` Nikolay Kudryavtsev
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2016-09-30 16:14 UTC (permalink / raw)
To: Nikolay Kudryavtsev; +Cc: 24565
> From: Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>
> Cc: 24565@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24565: 25.1: info freezes on some elements
2016-09-30 16:14 ` Eli Zaretskii
@ 2016-10-01 8:14 ` Nikolay Kudryavtsev
2016-10-01 8:45 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Nikolay Kudryavtsev @ 2016-10-01 8:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 24565
I did some bisecting, traced the offending commit to d5fdffe.
--
Best Regards,
Nikolay Kudryavtsev
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24565: 25.1: info freezes on some elements
2016-10-01 8:14 ` Nikolay Kudryavtsev
@ 2016-10-01 8:45 ` Eli Zaretskii
2016-10-01 8:55 ` Nikolay Kudryavtsev
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2016-10-01 8:45 UTC (permalink / raw)
To: Nikolay Kudryavtsev; +Cc: 24565
> From: Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>
> Cc: 24565@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24565: 25.1: info freezes on some elements
2016-10-01 8:45 ` Eli Zaretskii
@ 2016-10-01 8:55 ` Nikolay Kudryavtsev
2016-10-01 9:17 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Nikolay Kudryavtsev @ 2016-10-01 8:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 24565
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24565: 25.1: info freezes on some elements
2016-10-01 8:55 ` Nikolay Kudryavtsev
@ 2016-10-01 9:17 ` Eli Zaretskii
2016-10-01 9:32 ` Nikolay Kudryavtsev
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2016-10-01 9:17 UTC (permalink / raw)
To: Nikolay Kudryavtsev; +Cc: 24565
> From: Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>
> Cc: 24565@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24565: 25.1: info freezes on some elements
2016-10-01 9:17 ` Eli Zaretskii
@ 2016-10-01 9:32 ` Nikolay Kudryavtsev
2016-10-01 9:48 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Nikolay Kudryavtsev @ 2016-10-01 9:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 24565
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24565: 25.1: info freezes on some elements
2016-10-01 9:32 ` Nikolay Kudryavtsev
@ 2016-10-01 9:48 ` Eli Zaretskii
2016-10-08 19:37 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2016-10-01 9:48 UTC (permalink / raw)
To: Nikolay Kudryavtsev; +Cc: 24565
merge 24565 15876
thanks
> From: Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>
> Cc: 24565@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#24565: 25.1: info freezes on some elements
2016-10-01 9:48 ` Eli Zaretskii
@ 2016-10-08 19:37 ` Eli Zaretskii
0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2016-10-08 19:37 UTC (permalink / raw)
To: nikolay.kudryavtsev; +Cc: 24565-done
> Date: Sat, 01 Oct 2016 12:48:40 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 24565@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-10-08 19:37 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-09-29 7:30 bug#24565: 25.1: info freezes on some elements Nikolay Kudryavtsev
2016-09-29 15:13 ` Eli Zaretskii
2016-09-30 10:50 ` Nikolay Kudryavtsev
2016-09-30 12:22 ` Eli Zaretskii
2016-09-30 15:03 ` Nikolay Kudryavtsev
2016-09-30 16:14 ` Eli Zaretskii
2016-10-01 8:14 ` Nikolay Kudryavtsev
2016-10-01 8:45 ` Eli Zaretskii
2016-10-01 8:55 ` Nikolay Kudryavtsev
2016-10-01 9:17 ` Eli Zaretskii
2016-10-01 9:32 ` Nikolay Kudryavtsev
2016-10-01 9:48 ` Eli Zaretskii
2016-10-08 19:37 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).