bug-readline
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-readline] Pasting long lines is slow


From: Ole Laursen
Subject: Re: [Bug-readline] Pasting long lines is slow
Date: Thu, 21 May 2015 11:44:44 +0200

2015-05-20 22:57 GMT+02:00 Chet Ramey <address@hidden>:
> On 4/30/15 11:03 AM, Ole Laursen wrote:
>> Hi!
>>
>> I'm seeing what looks to me like quadratic behaviour on pasting long
>> lines in readline applications like bash, python, psql.
>>
>> To reproduce: open a new terminal with say bash, make a really long
>> line (> 20k characters, e.g. with python -c 'print "a" * 20000'), then
>> paste it into the terminal. The first characters are inserted quickly,
>> but it gradually slows down. With enough data it ends up being so slow
>> as to be unusable.
>
> I will be looking at this next.

Thanks!

I've been thinking about batching the input as it seems like an easier
fix compared to rewriting update_display. So I inserted a log into
insert_text:

  FILE *inserttextlog = fopen("inserttext.log", "a");
  fprintf(inserttextlog, "%i\n", l);
  fclose(inserttextlog);

And it looks like each character is indeed inserted one-by-one since
readline is reading them one-by-one from the input stream. There's a
_rl_insert_typein called from _rl_insert_char which looks like it's
actually taking care of a similar case of a series of rl_insert
characters, but only for stuffed characters and not for multibyte
cases.

I suppose one could try to generalize the _rl_insert_char code to grab
any rl_insert characters waiting in the input stream. Or just always
stuff everything waiting in the input stream.

Or decouple the display update from the line buffer modifications. The
update could then e.g. be driven from the input stream reader.

Or rewrite the call chain leading to _rl_insert_char so that it can
take a string and not just a single byte.


Ole



reply via email to

[Prev in Thread] Current Thread [Next in Thread]