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

Previous Next

Full log

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

From: fgallina <at> gnu.org (Fabián Ezequiel Gallina)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: andreas.roehler <at> easy-emacs.de, 16875 <at> debbugs.gnu.org
Subject: Re: bug#16875: python, comint-mode: Large output makes Emacs freeze
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.

One way to get that output in a file for testing is executing the
following shell command:

    python -c 'print ([[[False] * 200 for i in range(3)] for j in range(200)])' > /tmp/out.log

Even opening that file in fundamental-mode makes Emacs slow.  For
instance calling `previous-line' from the end of buffer several times
takes 1.1 seconds on average to complete.

    previous-line  30          33.263101639  1.1087700546

Next line is a bit more responsive though:

    next-line      30          14.028573178  0.4676191059

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


Cheers,
Fabián

Previous Next

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