GNU bug report logs - #16875
python, comint-mode: Large output makes Emacs freeze

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: fgallina <at> gnu.org (Fabián Ezequiel Gallina)
Cc: andreas.roehler <at> easy-emacs.de, 16875 <at> debbugs.gnu.org
Subject: bug#16875: python, comint-mode: Large output makes Emacs freeze
Date: Tue, 29 Jul 2014 10:32:10 +0300

> From: fgallina <at> gnu.org (Fabián Ezequiel Gallina)
> Cc: 16875 <at> debbugs.gnu.org,  andreas.roehler <at> easy-emacs.de
> Date: Mon, 28 Jul 2014 18:35:09 -0300
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: fgallina <at> gnu.org (Fabián Ezequiel Gallina)
> >> Date: Sat, 26 Jul 2014 23:22:41 -0300
> >> 
> >> 
> >> Emacs is still slow, but at least responds to commands.  I feel that
> >> everything that could be optimized on the comint side is pretty much
> >> there and that the slowness being experienced is in fact related to the
> >> long-lines slowness bug mentioned before[0].
> >
> > That bug is about displaying long lines.  Is the code that is slow
> > involved in displaying such lines?  If there's no display involved,
> > then the discussion you point to is not relevant.
> >
> > Also, please tell how long are your lines, on the average.
> >
> 
> Yes, such code outputs a long line consisting of 841601 chars.

In that case, yes, that's the "long line display slowness" problem.
If you profile Emacs with 'profiler-start' and 'profiler-report', you
should see that most of the time is spent in redisplay.

> Operations seem to take longer and longer as point moves away from the
> beginning of buffer.

That's expected, although the time should level out after some number
of lines.

Previous Next

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