On my system most terminals run this simple text output benchmark in
2-5 seconds:
time seq 100000
A new instance of 'xfce4-terminal' does it in 2 seconds.
Running it again in the same window takes 8 seconds, and consistently 8
after that. During those 8 seconds the CPU is at 100%.
Maximizing the window, tab #1, running the benchmark takes 2 seconds
again.
Unmaximizing the window, the time goes up to 8 seconds.
In another instance with eight tabs, it takes up to 47 seconds**, but I
haven't been able to reliably reproduce it in other windows, though
it's happened more than once. My X session begins with an autosaved
'xfce4-terminal' session with 8 tabs, that's the 47 seconds one.
Resizing the window fixes it, for a while.
(**not a side effect of background processes.)
This bug may be a symptom of:
#445323 cpu-intensive window redraw/window resize
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445323
...or perhaps not, since the slow text happens on my autosaved
session, before it's resized.
Hope this helps...
Here, whatever I do, with the window, it takes: seq 100000 0,12s user 0,13s system 53% cpu 0,480 total more or less. But if I open another tab, the time grows: seq 100000 0,26s user 0,23s system 26% cpu 1,796 total That's the only thing I can say. Do you have compositor deactivated in xorg? In xfwm? Cheers,
I can really reproduce this. On this other box, when the first window is opened, I get like 1 second. Then retry, still 1 second. I open another tab, try there, and get 2 seconds (wich is strange, I agree). Then retry in this tab, and 1 second. Same thing if I open another window. If I maximize the window, it's more like 6 seconds (wich is a lot but doesn't really surprise me) Unmaximizing, it's back to 1 sec. Opening 8 tabs doesn't change anything. First run is 2 sec, latter runs are 1 sec. Can you try to reproduce with gnome-terminal, too? As a side note, I'm using "fake" transparency (I can see the desktop trough the terminal window, but only the desktop) Cheers, -- Yves-Alexis
can't
Suggest adding a zero or two to see if the effect is more pronounced: time seq 1000000 # 10 or 20 seconds in theory Or... # patience time seq 10000000 # maybe 2 to 4 minutes? I tried 'konsole', 'gnome-terminal', 'xterm', 'rxvt', 'eterm', 'mrxvt' but so far haven't been able to slow down any other terminal. At first I tried 'em en masse like so: LOG=`mktemp -t terben.XXXXXX` C=100000 P="seq $C"; for f in 'xterm -e' 'rxvt -e' 'mrxvt -e' 'Eterm -e' 'konsole -e' 'gnome-terminal -x' 'xfce4-terminal -x'; do echo timing \"$f $P\".... ; $f /usr/bin/time -ao $LOG -f "%E real, %U user, %S sys, %P CPU :: $f" $P ; done ; cat $LOG timing "xterm -e seq 100000".... timing "rxvt -e seq 100000".... timing "mrxvt -e seq 100000".... timing "Eterm -e seq 100000".... timing "konsole -e seq 100000".... kbuildsycoca running... timing "gnome-terminal -x seq 100000".... timing "xfce4-terminal -x seq 100000".... 0:06.89 real, 0.16 user, 0.16 sys, 4% CPU :: xterm -e 0:03.38 real, 0.33 user, 0.38 sys, 21% CPU :: rxvt -e 0:02.00 real, 0.35 user, 0.36 sys, 35% CPU :: mrxvt -e 0:11.23 real, 0.18 user, 0.18 sys, 3% CPU :: Eterm -e 0:03.82 real, 0.16 user, 0.18 sys, 9% CPU :: konsole -e 0:04.17 real, 0.32 user, 0.42 sys, 17% CPU :: gnome-terminal -x 0:01.95 real, 0.17 user, 0.20 sys, 19% CPU :: xfce4-terminal -x But that code can't create the second tab, and doesn't reproduce the current bug. It shows 'eterm' is slowest, ordinarily. Note that I've used a '/usr/bin/time' command, as every shell seems to have a different internal 'time'. I tried the above with C=1000000 and the tail is surprising: timing "xfce4-terminal -x seq 1000000".... 0:32.00 real, 1.60 user, 1.74 sys, 10% CPU :: xterm -e 0:27.04 real, 3.95 user, 4.04 sys, 29% CPU :: rxvt -e 0:18.36 real, 3.41 user, 3.86 sys, 39% CPU :: mrxvt -e 1:54.52 real, 2.02 user, 1.97 sys, 3% CPU :: Eterm -e 0:37.18 real, 1.64 user, 1.80 sys, 9% CPU :: konsole -e 0:12.29 real, 1.85 user, 2.62 sys, 36% CPU :: gnome-terminal -x Not a copy & paste error, the last 'xfce4-terminal' never runs. This works: rm /tmp/foo ; xfce4-terminal -x /usr/bin/time -o /tmp/foo -f "%E real, %U user, %S sys, %P CPU " seq 100 ; cat /tmp/foo 0:00.00 real, 0.00 user, 0.00 sys, 0% CPU ...but not these: rm /tmp/foo ; xfce4-terminal -x /usr/bin/time -o /tmp/foo -f "%E real, %U user, %S sys, %P CPU " seq 10000 ; cat /tmp/foo cat: /tmp/foo: No such file or directory rm /tmp/foo ; xfce4-terminal -x /usr/bin/time -o /tmp/foo -f "%E real, %U user, %S sys, %P CPU " seq 1000000 ; cat /tmp/foo cat: /tmp/foo: No such file or directory The 'time' command might be suspect, except the other X terminals don't seem to be effected. I'm not sure, how do I check those? HTH...
10 seconds for runs in first tab. 11 seconds for first run in second tab. 10 seconds for second run in second tab. Could you test « by hand ». I'm not really interested in xterm, konsole etc., only gnome-terminal, because it's vte-based, like xfce4-terminal. On recent xorg you need to explicitely deactivate compositing, with:----8<---- Section "Extensions" Option "Composite" "disable" EndSection ---->8---- On xfwm you need to check in Settings Manager, Window Manager tweaks, tab « compositing » (wont be there if compositing is disabled in xorg). Cheers, -- Yves-Alexis
Have done so but the results seem inconclusive. I get results that
for 'seq 1000000' range over {9,14,15,46,52} seconds real time. I
opened about 50 tabs, that was the '14'.
Note that I had background processes going at the time, which might
account for it, but maybe not. Anyway, none of these runs compared
to the 'xfce4-terminal' slowness.
I haven't seen the 'xfce4-terminal' slowness in the last few days.
Retesting today... new instance, 1st tab 84s, run again 81s, 2nd tab
89s. Takes too long, I'll knock off a '0'. ' seq 100000' 2nd tab 9s,
9s, 9s; back to first 9s, 9s; hmmm, opened 50 tabs, 50th tab 39s, 37s;
try another 50, 100th tab slow at first but sped up -- 9s, 9s, 8s...
that starting slowness, if I do 'seq 10000' it takes 6s,8s,6s,6s,5s,6s,
adding a zero, back to 9s. Add a zero, 19s,20s,22s,17s.
The 6s for the 'seq 10000' in tab 100 looks like the kind of thing I had
before.
Tried tab 2 'seq 10000' in GnTerm again, 10s,0.7s,0.7s,0.7s. Tab 50
8s,8s,7s,9s. Opening tab 100 9s,4s,4s; try 'seq 100000', 8s,10s,7s.
In a nutshell, with many tabs, I see that the output speed of 'seq' is
not a flat line... it begins slowly then speeds up, by the looks of it
there seems to be two speeds or "gears", low gear 'seq 10000' 6s
(=~1800per/sec), high gear 999000 in 19-6=13s (=~.77000p/s).
% grep Composite /etc/X11/xorg.conf ; echo $?
1
It is and was enabled.
"Enable display compositing". It still needs to be off in X then?
Either way I'll test it soon... (but can't right now).
HTH...
PS: is there a way to automate opening a lot of tabs from the command
line and adding a command? That is, a way to tell the terminal "open
a window, then open 50 tabs, and in the 50th run 'foo'". 'expect' could
probably do it, but maybe there's some other way.
Ok so it doesn't seem really consistent :/ Note that it may have to do with the number of lines you keep in buffer (see terminal preferences). When you first run a command wich outputs a lot, the terminal will have to allocate the memory. Then it'll reuse the memory already allocated, so it'll be faster. ok Yes, it's activated in xorg but not in xfwm. Some people have reported that having compositing enabled but without compositor running can sow things a lot. Test it with compositing enabled in xfwm, and report back. Then test with compositing disabled in xorg, and report too. Anyway, it'll be slower when compositing is activated in xorg. Not really. Yet, I don't think it's a bug in terminal wich prevents you to use it. This kind of test just stress it a lot but any terminal will be more cpu-intensive when a lot of text is outputed fastly. Cheers,
My buffer is set to 1000 lines at present... which matches up with the 'seq 1000'. But if it's a one-time memory allocation delay, then shouldn't the second run of 'seq' should be faster? It wasn't; the "two-gear" effect was visible for every run. Yet tonight, I'm unable to reproduce the "two-gear" effect. Such a "heisenbug". Well when first I reported the bug the terminal speed was really slow; these stress tests were just attempts at reproducing that state. For sanity's sake I'll take a break for now, maybe some abler user will bump into it.
Yeah but her I couldn't reproduce at all :) And don't forget to retry without compositing :)
Hi guys, same problem with my lenny. If I use composite extension in xorg (no matter if you are using transparency effects on xfce or not), workspace switching when there are some xfce4-terminal open is very slow. Also using gnome-terminal. Now I switched to roxterm that doesn't has this annoying bug.
reassign 453266 libvte9 thanks Ok, this means that the problem lies in vte more than in xfce4-terminal vte managers: do you have a clue about this? Can you try with XLIB_SKIP_ARGB_VISUALS=1 exported before running xfce4-terminal (or gnome-terminal) and report back? Thanks,
That's because the terminal still draws the widget with an alpha channel (argb). To avoid this despit of the Composite extension, export the variable XLIB_SKIP_ARGB_VISUALS=1. mike
Now workspace switching is faster than light, even with 16 terminals open :D
Ciao !!! Non ho mai usato internet per scoprire .... Spero davvero che funziona :-) I miei amici dicono che sono molto simpatico, gentile, romantico, allegro .... Per me un sacco di qualita positive. Se mi si scrive, si avra una reale possibilita di vedere questo. Voglio trovare un uomo decente per relazione seria. Per favore mi dia la possibilita di fare la conoscenza con voi. Sono sicuro che non saremo delusi a vicenda !!! Ho intenzione di aspettare per la sua lettera nel mio indirizzo e-mail famigliavalentyna@mcsgreenprofile.net Cordiali saluti. Valentyna. Mio video https://goo.gl/1PFPZ9
Il mio foto galleria http://videos.timbervalleyfarm.com/ootowatywk password : 12345
Gentile cliente, Il tuo ordine di acquisto stato comunicato all'esercente che provvederа ad evaderlo in base alle condizioni di vendita definite. La conferma definitiva dell'acquisto la riceverai direttamente dall'esercente, che potrа confermarla o annullarla. Dati del negozio Codice Esercente: WEB_004579864646 Per scaricare i file da lei acquistati in formato digitale, deve loggarsi a questo file : fattura.xls Dati del pagamento Data e ora: 4/15/2020 2:03:49 PM Divisa: EUR Importo: 222,00 Codice XPay attribuito all'ordine di pagamento: L3291YT43861716 Codice autorizzativo assegnato dal circuito di pagamento: 96017483 Dati dell'acquirente Circuito della carta: VISA Indirizzo email dell'acquirente: 453266@bugs.debian.org
Gentile cliente, Il tuo ordine di acquisto stato comunicato all'esercente che provvederа ad evaderlo in base alle condizioni di vendita definite. La conferma definitiva dell'acquisto la riceverai direttamente dall'esercente, che potrа confermarla o annullarla. Dati del negozio Codice Esercente: WEB_00649673392 Per scaricare i file da lei acquistati in formato digitale, deve loggarsi a questo file : fattura.xls Dati del pagamento Data e ora: 4/22/2020 10:42:32 AM Divisa: EUR Importo: 4986,00 Codice XPay attribuito all'ordine di pagamento: J1228JP63733446 Codice autorizzativo assegnato dal circuito di pagamento: 145010 Dati dell'acquirente Circuito della carta: VISA Indirizzo email dell'acquirente: 453266@bugs.debian.org
Gentile cliente, Il tuo ordine di acquisto stato comunicato all'esercente che provvederа ad evaderlo in base alle condizioni di vendita definite. La conferma definitiva dell'acquisto la riceverai direttamente dall'esercente, che potrа confermarla o annullarla. Dati del negozio Codice Esercente: WEB_0045898265 Per scaricare i file da lei acquistati in formato digitale, deve loggarsi a questo file : fattura.xls Dati del pagamento Data e ora: 4/28/2020 5:29:25 AM Divisa: EUR Importo: 34,00 Codice XPay attribuito all'ordine di pagamento: C885ORI293923562 Codice autorizzativo assegnato dal circuito di pagamento: 239834 Dati dell'acquirente Circuito della carta: VISA Indirizzo email dell'acquirente: 453266@bugs.debian.org
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| Ciao. ****************************************************************************** _Piuttosto difficile scrivere la prima lettera, ma vorrei parlare con te._ .Un mio amico mi ha dato il tuo indirizzo mail.. -Non e uno scherzo, sono una ragazza seria.- :Mi chiamo ELENA e cercando uomo su Internet. : +Ti allego foto personali che puoi apprezzare.+ =Scrivimi se vuoi continuare la comunicazione. = |So che molte persone adesso sono a casa. | _E necessario rimanere in contatto con il mondo e condurre una conversazione su Internet. _ $Se sei aperto e vuoi continuare la conversazione, per favore rispondimi. $ ^Saro felice di ricevere le tue foto.^ _Forse mi scrivero ancora un po, o dirmi "Stop" ora._ |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| Il mio email bella@postale.casa Buona giornata.