[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16875: python, comint-mode: Large output makes Emacs freeze
From: |
Fabián Ezequiel Gallina |
Subject: |
bug#16875: python, comint-mode: Large output makes Emacs freeze |
Date: |
Mon, 28 Jul 2014 18:35:09 -0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: fgallina@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