bug#21028: Performance regression in revision af1a69f4d17a482c359d98c00ef86fac835b5fac (Apr 2014).

[Eli Zaretskii]

> Cc: 21028@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Mon, 13 Mar 2017 15:04:24 -0400
> 
> > I see nothing of the kind, as you saw.  With the same fonts as you 
> > use.  So it's definitely not a problem with the fonts.  Which is 
> > strange, since the profiles you provided seem to indicate a 
> > font-related problem.
> 
> We know the exact commit that caused this regression, right?  So how could 
> the problem not be font-related, since reverting it fixes the problem?

Because using the same fonts here doesn't reproduce the problem.
Which means that the font data is not the culprit, there's some other
factor at work here.

> > Is this the complete fontset setup you are using […] If it is, I will try 
> > to reproduce using this fontset.
> 
> No, not exactly.  The full thing is at 
> https://github.com/cpitclaudel/.emacs.d/blob/master/init/fonts.el#L7, but the 
> problem is reproducible in a clean install an a much simpler set up.

Thanks, I will try using one of these, maybe it will help me reproduce
the problem.

> What about the VM approach, or simply remote access on a VM that I could 
> provide?

Debugging display problems without seeing the display is not
practical.

> Do you want to reproduce the problem to debug it locally, or something else? 
> If the former, it there nothing I could do to help?

The former, of course.  This happens in complicated code I know very
little about, and no one else on board knows more.  Stepping through
the code with a debugger, comparing the "fast" path with the "slow"
path is the only way to understand what is going on there.

> Would it help if I tried to find other people who can reproduce the problem 
> on their machines by following my VM-based reproduction steps?

If they can debug the problem and explain why the slowdown is so
massive, yes.  Otherwise, we are back to square one.