1

Whenever there are many brackets drawn in the gnome-terminal window, things start to lag pretty badly. This effect is especially apparent, when the brackets don't have anything in between them, which means that the sequence [][][]... produces considerably more lag than [a][a][a]..., but the sequence [],[],[],... also produces more lag than the 2nd sequence. The problem does not persist with pure letter sequences (tested with aaa... and ababab...)

Also, it seems that for this effect, (),{},[] are interchangeable.

Bash has been ruled out as a source by first using sh and then another terminal emulator (i3-sensible-terminal in i3) and a terminal (Ctrl+Alt+F3-F6 on Fedora) (with bash), which also shows, that it's probably specific to gnome-terminal, as there was absolutely no lag with i3-sensible-terminal or a terminal, but the problem did occur in i3 and Fedora's default WM (Mutter) using gnome-terminal.

I have originally encountered this problem, while playing around with the repeat function in ghci (haskell shell), which lagged the terminal down, for as long, as the brackets were present. After this, I tried to reproduce the output in bash by echoing a string, and the effect was the same.

In bash, I did this in 2 ways:

#Method 1
d="[]"
d=$d$d$d$d$d #executed this line 5-7 times
echo $d

#Method 2
d=""
for i in {1..1000}; do d+="[]"; done
echo $d

and in ghci (haskell shell) I did it also in multiple ways:

repeat [] --this is infinitely executed
repeat [1] --same as line 1, but doesn't lag the system
take 1000 (repeat []) --lags the system as well, but stops after 1000 brackets

So, my question is: What reason is there, that, specifically in gnome-terminal, having bracket pairs on screen is way more expensive than having other character sequences printed out?

Miko Nator
  • 11
  • 3
  • it should be noted, that this string should fill out an entire screen, and the terminal should be fullscreen as well, maybe the characters would need to be reduced in size, but the effect is quite apparent on my distro. – Miko Nator Oct 25 '21 at 19:54
  • You say, "I tried to reproduce the output in bash by echoing a string" ... Can you [edit] your post to include the exact, specific shell commands you have used to create the problem? Are you sure you're not invoking a fork bomb of some kind? – Jim L. Oct 25 '21 at 19:54
  • yes, I'm sure, that ghci and bash would not invoke a fork bomb by default. I have tested out fork bombs on an installation, and the results would be vastly different. Also, Fork Bombs can't be stopped with Ctrl+L – Miko Nator Oct 25 '21 at 19:56

0 Answers0