On 07/15/2015 06:32 AM, Dmitry Antipov wrote:
> On 07/10/2015 07:55 PM, Clément Pit--Claudel wrote:
> 
>> The figures are very similar to the tests above: with that patch inserting 50 lines takes 3 seconds,
>> and without it it's instantaneous. Thus I think it's safe to say that this particular patch is indeed
>> responsible for the performance regression. But maybe I'm missing something?
> 
> As of c40ea1328bb33abaec14f1fc92ac2349b5ee2715, I can't reproduce this issue, with your fontset setup
> from http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21028#17. Cursor motion and keyboard/mouse selection
> are smooth, and CPU/memory usage looks normal.

I'm still receiving bug reports from users of my plugins about slowness; this doesn't seem to affect just me. I can reproduce it in the latest pretest. My bet is that this is due to specific fonts. That would explain why you couldn't reproduce this.

(I'm getting reports because my mode enables prettify-symbols-mode, and thus displays characters from fallback fonts)

I've removed the dependency on CJK fonts; on my machine, this does the trick, provided you have XITS Math and Ubuntu Mono installed:

emacs -Q --eval "(progn (set-fontset-font \"fontset-startup\" 'unicode \"Ubuntu Mono\" nil) (set-fontset-font \"fontset-startup\" 'unicode \"XITS Math\" nil 'append) (dotimes (_ 500) (insert (make-string 20 8658) \"\n\")))"

Scrolling around this buffer is horribly slow.

I would very much welcome help in tracking and fixing this bug. The culprit is af1a69f4d17a482c359d98c00ef86fac835b5fac, but if the commit itself can't be reversed, maybe we could find another way to achieve what it does?

Clément.