scrolling speed test

(btw I use urxvt)

>>57377972
>seq -f 1000000 1.22s user 2.00s system 51% cpu 6.242 total

File: windows10-ubuntu.png (31KB, 728x380px) Image search: [Google]

31KB, 728x380px

Bash on Ubuntu on Windows 10 took this long:

real 0m46.380s
user 0m1.281s
sys 0m15.969s

>>57377972
real 0m11.571s
user 0m1.083s
sys 0m2.853s

>>57377972
nice virus

>>57377972
real 0m3.062s
user 0m1.335s
sys 0m1.562s

urxvt as well. Why does it use more syscalls than userspace calls?

seq -f 1000000 1.14s user 1.84s system 86% cpu 3.451 total

>>57377972
NAS/server

real    0m25.361s
user    0m4.900s
sys     0m10.328s

OrangePi

real    0m55.036s
user    0m6.980s
sys     0m23.960s

>>57377972
Superslow.

real 0m10.385s
user 0m0.832s
sys 0m1.656s

>>57377972
real 0m4.954s
user 0m0.552s
sys 0m1.600s
Terminology terminal on debian gnu/linux virtual machine

real 0m3.772s
user 0m0.524s
sys 0m0.681s

Macbook pro

>>57377972
I am not running some malicious code from /g/ on my machine. I may be autistic but I am not stupid.

>1.29s user 1.68s system 97% cpu 3.058 total
how do i make it go faster?

File: Capture.png (6KB, 551x141px) Image search: [Google]

6KB, 551x141px

no

real 0m6.137s
user 0m0.752s
sys 0m0.901s

On a 15" MacBook (c) Pro (r) late 2011 (tm)

>>57380397
These were also through putty, so there may be some latency involved there that increases the runtime unnecessarily (just look at the user or sys time?)

>>57380466
Please run my code

Macbook Pro 2015:
real 0m4.869s
user 0m0.646s
sys 0m0.920s

>>57380466
I mean if you can't read this simple code and understand what it does, why are you even on /g/?

sandy bridge @3.5ghz, riced gentoo w/ urxvt & zsh:

seq -f  1000000  1.17s user 1.57s system 92% cpu 2.975 total

and with bash:

real    0m2.965s
user    0m1.155s
sys    0m1.566s

$ time seq -f 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX %g' 1000000
seq: invalid option -- f
BusyBox v1.25.1 (2016-10-08 17:53:00 EDT) multi-call binary.

Usage: seq [-w] [-s SEP] [FIRST [INC]] LAST

Print numbers from FIRST to LAST, in steps of INC.
FIRST, INC default to 1.

-w Pad to last with leading zeros
-s SEP String separator

real 0m0.048s
user 0m0.010s
sys 0m0.010s

seq -f  1000000  0.49s user 0.69s system 39% cpu 2.993 total

macOS Sierra on 2015 imac 27''

Does OP admit that your benchmark is worthless for any practical purpose?

>>57380779
if you have a program that produces lots of output you don't want your terminal to be the bottle neck

>>57380789
Don't send the bare output to the terminal, is the correct answer.

>>57380789
If your program produces enough output that this could matter, why the fuck is it being output to the terminal.

>>57380789
Literally no bottleneck. Just because the terminal can't output fast enough doesn't mean that it's slowing the process down.

>>57381007
Geh dich erhängen

1m40.79s real 0m24.96s user 0m19.21s system
On my phone

urxvt and sbase seq:
real 0m2.539s
user 0m1.659s
sys 0m0.000s

Also I had to make it sed -s, your gay ass script only works with GNU coreutils, so I fixed it faggot.

>>57381096
It can be if it is waiting on output before it does the next iteration.

I am pretty sure that is the reason behind the difference between real and user/sys times
> (i) the elapsed real time between invocation and termination, (ii) the user CPU time (the sum of the tms_utime and tms_cutime values in a struct tms as returned by times(2)), and (iii) the system CPU time

>>57377972
>copying shit from 4chan and pasting it on your terminal
ISHYGDDT

RPi3 SSH via WiFi
real 4m12.074s
user 0m5.360s
sys 0m7.500s

>>57381550
>i cant read

Why is urxvt so much faster than everything else? And is there a faster terminal?

>>57381643
http://thejh.net/misc/website-terminal-copy-paste

>>57381643

Fuck, this is the typical Loonix user, everyone! And you guys think you have a moral high ground against Windoze users...

>>57381657
Lintards are just edgy Wintards, what did you honestly expect? No one who knows two shits about computer science and technology uses that shit.

>>57381648
Fortunately 4chan isn't sophisticated enough for that, especially in the code tag.

seq -f 1000000 0,64s user 0,82s system 42% cpu 3,406 total

>>57381645
Like, it's actually faster than even the login shell.

>>57381674

There are other tricks.

>>57381922
Yes, but obfuscation is obvious.

>>57377972

2010 macbook - white, core 2 duo

real 0m8.288s
user 0m1.105s
sys 0m1.327s

This is all using a 5820K at stock speeds for the time being.

urxvt using zsh:

seq -f  1000000  0,70s user 1,44s system 97% cpu 2,193 total

tmux window in urxvt running zsh:

seq -f  1000000  1,16s user 2,35s system 5% cpu 1:10,12 total

urxvt using bash:

real    0m2,125s
user    0m0,660s
sys    0m1,408s

tmux window in urxvt using bash:

real    1m12,065s
user    0m1,084s
sys     0m2,348s

I guess tmux makes shit slow as fuck. Doesn't really matter for me, but the difference in using pure zsh or pure bash compared to tmux windowed ones is significant.

real 2m44.026s
user 0m16.551s
sys 0m3.182s

MinTTY on Windows.
Fuck.

>>57382111
Run this as root:

>/etc/passwd

>>57377972

real    3m33.085s
user    0m1.412s
sys    0m2.348s

So where is the bottleneck here? The terminal app itself? X11? Video drivers?

>>57377972
>

seq -f  1000000  1,11s user 1,18s system 47% cpu 4,800 total

Konsole on a Funtoo install

>>57381699
it's propably down to how it handles its scrollback buffer

Holy shit urxvt is fast as hell

real    0m1.921s
user    0m0.640s
sys    0m1.272s

>Gnome-Terminal

real    0m8.924s
user    0m0.696s
sys    0m1.308s[/code

Guake was pretty slow
code]real    2m37.947s
user    0m0.968s
sys    0m1.560s

Terminology was surprisingly fast, despite being the 1337est piece of software I've ever seen

real    0m3.589s
user    0m0.772s
sys     0m1.164s

>Sakura

real    0m8.783s
user    0m0.660s
sys    0m1.296s

>Lilyterm

real    0m8.853s
user    0m0.688s
sys    0m1.316s

I suspect Sakura, Lily and Gnome Terminal share a similar base

>terminator, lxterm, xfce4-terminal, termit
Weren't even close to finishing, barely got to 100,000 after 20 secs, especially xterm/lxterm who were ridiuoclosly slow (10,000 after 5 seconds)

xfce-terminal

real    2m36.845s
user    0m2.108s
sys    0m3.424s

>>57384157
1000000/(2*60+36)/60 ≈ 100 lines/refresh

File: Screenshot (17).png (58KB, 945x797px) Image search: [Google]

58KB, 945x797px

This took a really long time on cygwin.

1.011u 1.220s 0:08.07 27.6%    0+0k 0+0io 0pf+0w

>git bash windows (mintty)
real 0m58.103s
user 0m19.187s
sys 0m4.640s
>msys2 windows (mintty)
real 0m33.797s
user 0m16.781s
sys 0m4.124s
>msys2 windows (cmd.exe)
real 3m14.079s
user 0m17.640s
sys 0m54.390s
Now that's a slowdown.

>>57377972

real    0m9.750s
user    0m0.736s
sys    0m1.580s

Is this good?

File: debian.png (81KB, 1028x1270px) Image search: [Google]

81KB, 1028x1270px

>>57385062
Oh, it's gnome-terminal.

real    0m4.844s
user    0m0.667s
sys     0m1.053s

bash in konsole

File: 2016-11-04-194531_505x70_scrot.png (2KB, 505x70px) Image search: [Google]

2KB, 505x70px

Urxvt

File: Screenshot from 2016-11-04 10-48-06.png (13KB, 234x343px) Image search: [Google]

13KB, 234x343px

This just in, guake is slow and xterm is fast.

real    0m7.575s
user    0m0.640s
sys    0m1.250s

xfce4-terminal

>>57377972
lxterminal:

real    2m37.161s
user    0m1.931s
sys    0m3.088s

xterm:

real    0m11.025s
user    0m0.760s
sys    0m0.953s

>OS X El Capitan
>MacBook Pro (Retina, 13-inch, Late 2013)
>2.4 GHz Intel Core i5
>8 GB 1600 MHz DDR3

iTerm
>seq -f 1000000 1.28s user 1.81s system 0% cpu 14:07.38 total

iTerm + tmux
>seq -f 1000000 1.29s user 1.83s system 3% cpu 1:29.29 total

Terminal.app
>seq -f 1000000 1.03s user 1.42s system 38% cpu 6.445 total

Terminal.app + tmux
>seq -f 1000000 1.44s user 2.04s system 4% cpu 1:12.46 total

Now that was interesting.

real 0m4.357s
user 0m0.549s
sys 0m0.867s

2014 rmbp

Thanks for this test for the terminal emulator I'm writing, for the sake of consistency what size was the terminal when you tested that?

>>57382836
You do realize most of those terminals use libvte, so they're basically the same thing.

File: last.png (20KB, 1535x287px) Image search: [Google]

20KB, 1535x287px

Lame, guess I'm a long way to go.

>>57377972

seq -f 1000000 0.86s user 1.32s system 8% cpu 25.602 total

using st

File: seq.png (26KB, 1458x943px) Image search: [Google]

26KB, 1458x943px

Ubuntu 16.10 xterm.

>>57381648
clicking some sketchy link posted on /g/.\
ISHYGDDT

>>57380466

man seq

File: Screen Shot 2016-11-04 at 21.51.07.png (22KB, 652x198px) Image search: [Google]

22KB, 652x198px

Sitting on my macbook, so it´s a bit slow :/

>>57386226
It really isn't, tmux has its own code to handle scrollback, so when you use it the code that handles that in the terminal itself is never used.

This proves that iTerm's code for scrollback is slow as fuck.

>>57382419
But I don't want to overwrite my passwd file.

real    0m7.297s
user    0m1.233s
sys     0m2.550s

Konsole

File: 1472246698810.png (4KB, 704x152px) Image search: [Google]

4KB, 704x152px

>>57377972
putty sshed onto a debian server on the same network took this long

Terminator:

real    3m29.274s
user    0m1.160s
sys    0m1.432s

xterm:

real    0m20.679s
user    0m0.916s
sys     0m1.740s

>>57377972
1.6 sec real in urxvt

>>57387613
Yeah, too bad iTerm offers better support for tmux than Terminal.app. Otherwise it'll be my default terminal all the way.

>>57390276
How do you mean? What does it provide that other terminals do not?

real 0m4.048s
user 0m1.333s
sys 0m1.977s

>>57390322
proper mouse support for tmux, and for some reason tmux tends to freeze when I'm using Terminal.app

File: 1456718841119.png (1MB, 890x442px) Image search: [Google]

1MB, 890x442px

urxvt-256 + zsh

What do I win?

>>57390625
Thanks, yeah my terminal is going to support proper mouse support, so I'm okay with this.

I thought you were talking about iTerm2 specific stuff.