First of all this isn’t meant to be accurate or very reliable, even flawed, I just want to see some numbers, because in pymux‘s README, it mentions about the performance, but not actual numbers:
Tmux is written in C, which is obviously faster than Python. This is noticeable when applications generate a lot of output. Where tmux is able to give fast real-time output for, for instance find / or yes, pymux will process the output slightly slower, and in this case render the output only a few times per second to the terminal. Usually, this should not be an issue. If it is, Pypy should provide a significant speedup.
1 Method
I use my own test script, termfps.sh, which is written in Bash. I thought about using find or yes as mentioned in the README, but I am too lazy to write a script for the tests, I used what I already have in hand.
Since pymux is written in Python, so I tested with two implementations, the official CPython and PyPy (RPython to C). They will all run within the environment virtualenv creates, and using pip to install pymux 0.5 and Pyte 0.4.10, and along with their dependencies.
The test script is run with reset && ./termfps.sh in urxvtc with font xft:Envy Code R:style=Regular:size=20:antialias in dwm with virtually full-screen of 1680x1050, dwm topbar is hidden, and the window size is 1669x1027 and geometry is 111x33.
Both tmux and pymux are run without configuration files.
2 Used versions
name | version | note |
---|---|---|
urxvt | 9.21 | x11-terms/rxvt-unicode-9.21 |
termfps.sh | 2014-09-06 | git-00559f9 |
tmux | 1.8 | app-misc/tmux-1.8 |
Python | 2.7.10 | dev-lang/python-2.7.10-r1 |
Python | 3.4.3 | dev-lang/python-3.4 |
PyPy | 4.0.1 | dev-python/pypy-bin-4.0.1 |
PyPy32 | 2.4.0 | dev-python/pypy3-bin-2.4.0-r1 |
virtualenv | 12.0.5 | dev-python/virtualenv-12.0.5 |
Pymux | 0.5 | |
six | 1.10.0 | |
prompt-toolkit | 0.57 | |
Pyte1 | 0.4.10 | |
docopt | 0.6.2 | |
Pygments | 2.0.2 | from prompt-toolkit |
wcwidth | 0.1.6 | from prompt-toolkit |
[1] | The latest Pyte 0.5.x (2016-01-11) doesn’t work with pymux 0.5. |
[2] | PyPy3, there is a bug and can’t be worked with virtualenv, the latest 2.4.0 (2014-10-09) doesn’t include the fix (2015-02-06). The test is run without virtualenv created environment. |
3 Result
From the fastest to slowest by the elapsed time:
test with | version | lines3 | elapsed | fps | cps |
---|---|---|---|---|---|
urxvtc4 | 9.21 | 33 | 000.497 | 200.879 | 735,822 |
tmux | 1.8 | 32 | 001.786 | 055.962 | 198,779 |
Python | 2.7.105 | 31 | 028.237 | 003.541 | 012,185 |
PyPy | 4.0.1 | 31 | 057.751 | 001.731 | 005,958 |
PyPy | 2.4.0 | 31 | 070.458 | 001.419 | 004,883 |
Python | 3.4.36 | 31 | 128.130 | 000.780 | 002,685 |
[3] | Because of titlebar and/or status bar, there will be different in lines. |
[4] | urxvt is run without anything but the script, this is just for reference. |
[5] | Python 2.7.10 isn’t working properly. From my eyes, I can not see some frames, it goes like 1, 4, 8, 2, 5, and so on. Some frames doesn’t not seem displayed. |
[6] | All Python versions but PyPy3 are run within virtualenv created environments. |
4 Conclusion
Although there is terminal lines differences up to 2 lines, but since results vary significantly, I ignored the lines without normalizing those numbers.
By numbers, Python 2 seems to win, but as the note above, it’s flawed. Some frames I didn’t see. However, that doesn’t mean those frames are dropped by pymux. They could somehow be buffered and flushed out with other frames, or some other explanations.
The only comparison can be done is between tmux and pymux (Python 3/PyPy/PyPy3). By the elapsed times:
- Pymux (Python 3) is 81.85% slower than pymux (PyPy3) and 7,074% slower than tmux.
- Pymux (PyPy3) is 3,845% slower than tmux and 22% slower slower than pymux (PyPy).
Of course, it’s a bit of extreme since the test script prints out the entire frame of characters at once, if I recall correctly. In real world case, most of program doesn’t do full terminal size updates. Such as find and yes are outputting line by line, and they won’t be full width every line.
The numbers, either 7,074% and 3,845%, are looking horrible, but the actual user experience with daily programs might not reflect those numbers.
0 comments:
Post a Comment
Note: Only a member of this blog may post a comment.