Pasting Extremely Slow on CentOS 5

[tgt]

I just upgraded to fish 2.2.0 on CentOS 5.11. Since upgrading it takes a long time for the text I paste into the terminal to finish appearing, around 4 seconds to paste 50 characters.

It's also fairly slow to paste into a terminal running on Ubuntu 12.04, but only takes about half a second. There are no problems on a machine running Debian 8.

Anything I can do or provide to help debug the issue?

[faho]

What terminal are you using? What are you pasting? Does it contain weird characters?

Does it always take that long or just sometimes?

[tgt]

I'm using GNOME Terminal 3.4.1.1 running on Ubuntu 12.04. The examples I gave above were all using this terminal, the CentOS 5 and Debian examples were machines I'd SSHed into from the Ubuntu machine.

Everything I paste takes that long and it always takes that long. I timed it with a string of 50 "a"s.

It visually adds characters in chunks of 4 or so characters and I can press Ctrl-C to stop the pasting. Pressing Ctrl-C does not erase already pasted characters, just prevents further characters appearing.

[faho]

So it's exacerbated by SSH, but also a bit slow (50 "a"s should be instantaneous) without it?

Please upload your config.fish, custom functions (especially your prompt and all signal handlers) and any other configuration that might be important.

[tgt]

Oh, no, it isn't exacerbated by SSH. The fastest machine is my Debian machine, which is over SSH and instantaneous. In order of speed:

Debian 8 (over SSH, not local) > Ubuntu 12.04 (no SSH, local) > CentOS 5 (over SSH, VM on same machine as Ubuntu)

I have nothing in ~/.config/fish/functions and do not have a ~/.config/fish/config.fish. What other relevant configuration could I provide?

Pasting into vim or bash or a MySQL prompt is instantaneous on the CentOS machine.

[faho]

I have nothing in ~/.config/fish/functions and do not have a ~/.config/fish/config.fish.

On none of the machines? Are all machines on fish 2.2.0?

Can you try a different terminal (like xterm or console)?

[zanchey]

Possibly the output of strace -ttTf would be helpful. If you need a hand with the syntax, let us know.

[tgt]

They're all running 2.2.0. None of them have anything configured. (They did, but I removed them all whilst trying to determine what could be causing this issue.)

The issue still occurs when using xterm and PuTTY.

A trace can be found at https://www.dropbox.com/s/k4udf1zme1e5nsa/fish-trace.txt?dl=0

I made it using strace -ttTf fish 2> fish-trace.txt, pasting into the shell and then pressing Ctrl-D. If that's not the right way to do it I can make another one.

[zanchey]

Weird! Certainly in the trace it looks like the characters are all read and written in quick succession in the trace; the last 'a' is written 150 msec after the first one is read, to my reading.

[tgt]

First character read:
14:03:57.535448 read(0, "a", 1) = 1 <0.000027>

Last character written:
14:03:59.845507 write(1, "a", 1) = 1 <0.000122>

That's a little over two seconds. Unless I'm reading it wrong?

[zanchey]

That's after you pressed return, I think - it's been written to the history already at that point. 14:03:57.681106 is the last time it's written to stdout as it's being read.

[tgt]

Yup, you're right. Very strange. Anything else I can provide to help?

[tgt]

I used git bisect and it pointed to 722fedc being the cause of the slowness. Reverting the commit does indeed fix pasting. I haven't looked into the code yet.

[ridiculousfish]

Nice work

[tgt]

Sorry for the duplicate references. I accidentally created my pull request on my fork rather than this repo.

[tgt]

I'm no longer at a computer that can build fish, so that second commit was a bit of a guess. I'll fix this in the evening.

[ridiculousfish]

Here is the patch that I plan to test:

diff --git a/src/input.cpp b/src/input.cpp
index d6c46ea..e872866 100644
--- a/src/input.cpp
+++ b/src/input.cpp
@@ -570,7 +570,7 @@ static void input_mapping_execute(const input_mapping_t &m, bool allow_commands)
         return;
     }

-    if (!allow_commands)
+    if (has_commands && !allow_commands)
     {
         /* We don't want to run commands yet. Put the characters back and return
            R_NULL */

I'm trying to get CentOS 5 installed. If someone can beat me to it let me know if it works!

[tgt]

Well, that's a lot simpler than my suggestion!

I can confirm that your patch fixes the issue. I'm testing it on OS X 10.11. I wonder why I'm the only one that can see the issue and can see it on multiple machines.

[ridiculousfish]

I think I'm able to reproduce this on my OS X box too. My fix definitely fixes it. I'm going to merge it.

[ridiculousfish]

We ought to relnote this

[pickfire]

After that commit, pasting still seems slow on Linux and doesn't look to be having a big difference although it is a bit faster.

[ridiculousfish]

@pickfire what's your config?

[pickfire]

@ridiculousfish https://github.com/pickfire/dotfiles/tree/alarm/home/config/fish

I think the main reason why it is slow because I am using Raspberry Pi and it could be good for testing the speed of fish.

[pickfire]

@ridiculousfish If you need the trace, here is it. http://sprunge.us/AgTW

[pickfire]

It seems that pasting when using root is 2x faster than using a normal user.
And when fish has been running for a long time, pasting in root is 3x faster than a normal user.

The recording of the paste:
https://asciinema.org/a/4udcn14ee3k7uzetonug5l6nm

[faho]

@pickfire: I can't reproduce, neither on my laptop nor on my rasbpi via ssh. Though I'm currently building a newer fish on the latter (had 2.2.0-367-something), maybe it's a regression.

Do you still get this?

[pickfire]

@faho, I have just tested it, it seems like it is a lot faster compared to what I get some time ago. I think this can be closed.

[faho]

Closing it is. Thanks!