2015-08-08 02:11:30 +00:00
|
|
|
|
.. image:: imgs/icon_faq.png
|
|
|
|
|
:align: right
|
|
|
|
|
:alt: Because curious cats ask clever code monkeys.
|
|
|
|
|
|
|
|
|
|
==========================
|
|
|
|
|
Frequently Asked Questions
|
|
|
|
|
==========================
|
|
|
|
|
|
|
|
|
|
Here I'll try to list some common questions that get asked for.
|
|
|
|
|
|
|
|
|
|
------
|
|
|
|
|
Why...
|
|
|
|
|
------
|
|
|
|
|
|
|
|
|
|
...write in Python? It's slow/bloated/bad?
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
Performance
|
|
|
|
|
~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Profiles were configured with command ``bash -c exit``, and the
|
|
|
|
|
commands run a couple of times to get the caches loaded up.
|
|
|
|
|
|
|
|
|
|
GNOME-Terminal::
|
|
|
|
|
|
|
|
|
|
time for i in {1..30} ; do gnome-terminal --profile=Quickexit; done
|
|
|
|
|
|
|
|
|
|
real 0m10.606s
|
|
|
|
|
|
|
|
|
|
Terminator::
|
|
|
|
|
|
|
|
|
|
time for i in {1..30} ; do terminator -g deletemeconfig -p Quickexit; done
|
|
|
|
|
|
|
|
|
|
GTK2: real 0m11.928s A smidgen slower.
|
|
|
|
|
GTK3: real 0m10.885s Yeah, basically identical!
|
|
|
|
|
|
|
|
|
|
Cold start, using ``sync && echo 3 > /proc/sys/vm/drop_caches`` before
|
|
|
|
|
each run, then launching a single timed instance.
|
|
|
|
|
|
|
|
|
|
Gnome-Terminal::
|
|
|
|
|
|
|
|
|
|
time gnome-terminal --profile=Quickexit
|
|
|
|
|
|
|
|
|
|
real 0m7.628s (approx median, there was a strange variance for GT, between 5 and 9 secs)
|
|
|
|
|
|
|
|
|
|
Terminator::
|
|
|
|
|
|
|
|
|
|
time terminator -g deletemeconfig -p Quickexit
|
|
|
|
|
|
|
|
|
|
GTK2: real 0m11.390s (median of 3x)
|
|
|
|
|
GTK3: real 0m11.264s (median of 3x)
|
|
|
|
|
|
|
|
|
|
OK, so this is the once place you would notice an appreciable
|
|
|
|
|
difference. How often do you start these things with completely empty
|
|
|
|
|
caches/buffers?
|
|
|
|
|
|
|
|
|
|
In GTK2 there is a known issue which slows the cat'ing of large files
|
|
|
|
|
quite a bit. The VTE in GTK3 Terminator is the *exact* same widget
|
|
|
|
|
GNOME-Terminal uses, so this will get better, as and when we move
|
|
|
|
|
fully to the in-progress GTK3 port. I should point out that this
|
|
|
|
|
performance deficit is not due to the Python interpreter, or the
|
|
|
|
|
Terminator Python code, but is solely down to the compiled C code VTE
|
|
|
|
|
widget.
|
|
|
|
|
|
|
|
|
|
Memory use - The dumb way
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
GNOME-Terminal::
|
|
|
|
|
|
|
|
|
|
for i in {1..100} ; do gnome-terminal --disable-factory & done
|
|
|
|
|
|
|
|
|
|
root@pinpoint:~# sync && echo 3 > /proc/sys/vm/drop_caches && free # Before startup
|
|
|
|
|
total used free shared buffers cached
|
|
|
|
|
Mem: 3102404 1388776 1713628 4052 164 45340
|
|
|
|
|
-/+ buffers/cache: 1343272 1759132
|
|
|
|
|
Swap: 3121996 788704 2333292
|
|
|
|
|
root@pinpoint:~# sync && echo 3 > /proc/sys/vm/drop_caches && free # After startup
|
|
|
|
|
total used free shared buffers cached
|
|
|
|
|
Mem: 3102404 2439524 662880 57196 1240 99212
|
|
|
|
|
-/+ buffers/cache: 2339072 763332
|
|
|
|
|
Swap: 3121996 751440 2370556
|
|
|
|
|
root@pinpoint:~# sync && echo 3 > /proc/sys/vm/drop_caches && free # After kill
|
|
|
|
|
total used free shared buffers cached
|
|
|
|
|
Mem: 3102404 1466536 1635868 4796 160 45912
|
|
|
|
|
-/+ buffers/cache: 1420464 1681940
|
|
|
|
|
Swap: 3121996 751020 2370976
|
|
|
|
|
|
|
|
|
|
Used (used mem -buffers/cache + swap)
|
|
|
|
|
Before start: 2131976
|
|
|
|
|
After start : 3090512 = 958536 kbytes, 936 Mbytes / 9.36 MBytes/instance
|
|
|
|
|
After kill : 2171484 = 39508 kbytes, 38 Mbytes not recovered
|
|
|
|
|
|
|
|
|
|
Terminator GTK2::
|
|
|
|
|
|
|
|
|
|
for i in {1..100} ; do terminator -g deletemeconfig -u & done
|
|
|
|
|
|
|
|
|
|
root@pinpoint:~# sync && echo 3 > /proc/sys/vm/drop_caches && free
|
|
|
|
|
total used free shared buffers cached
|
|
|
|
|
Mem: 3102404 1313456 1788948 4284 152 43844
|
|
|
|
|
-/+ buffers/cache: 1269460 1832944
|
|
|
|
|
Swap: 3121996 736844 2385152
|
|
|
|
|
root@pinpoint:~# sync && echo 3 > /proc/sys/vm/drop_caches && free
|
|
|
|
|
total used free shared buffers cached
|
|
|
|
|
Mem: 3102404 2866552 235852 19484 1084 65408
|
|
|
|
|
-/+ buffers/cache: 2800060 302344
|
|
|
|
|
Swap: 3121996 736340 2385656
|
|
|
|
|
root@pinpoint:~# sync && echo 3 > /proc/sys/vm/drop_caches && free
|
|
|
|
|
total used free shared buffers cached
|
|
|
|
|
Mem: 3102404 1317724 1784680 4284 152 43464
|
|
|
|
|
-/+ buffers/cache: 1274108 1828296
|
|
|
|
|
Swap: 3121996 736304 2385692
|
|
|
|
|
|
|
|
|
|
Used (used mem -buffers/cache + swap)
|
|
|
|
|
before start: 2006304
|
|
|
|
|
after start : 3536400 = 1530096 kbytes, 1494 Mbytes / 14.94 MBytes/instance
|
|
|
|
|
after kill : 2010412 = 4108 kbytes, 4 Mbytes not recovered
|
|
|
|
|
|
|
|
|
|
Terminator GTK3::
|
|
|
|
|
|
|
|
|
|
for i in {1..100} ; do terminator -g deletemeconfig -u & done
|
|
|
|
|
|
|
|
|
|
root@pinpoint:~# sync && echo 3 > /proc/sys/vm/drop_caches && free
|
|
|
|
|
total used free shared buffers cached
|
|
|
|
|
Mem: 3102404 1467204 1635200 4816 120 46132
|
|
|
|
|
-/+ buffers/cache: 1420952 1681452
|
|
|
|
|
Swap: 3121996 751000 2370996
|
|
|
|
|
root@pinpoint:~# sync && echo 3 > /proc/sys/vm/drop_caches && free
|
|
|
|
|
total used free shared buffers cached
|
|
|
|
|
Mem: 3102404 2848372 254032 7216 960 52652
|
|
|
|
|
-/+ buffers/cache: 2794760 307644
|
|
|
|
|
Swap: 3121996 750016 2371980
|
|
|
|
|
root@pinpoint:~# sync && echo 3 > /proc/sys/vm/drop_caches && free
|
|
|
|
|
total used free shared buffers cached
|
|
|
|
|
Mem: 3102404 1483388 1619016 4820 148 46084
|
|
|
|
|
-/+ buffers/cache: 1437156 1665248
|
|
|
|
|
Swap: 3121996 749828 2372168
|
|
|
|
|
|
|
|
|
|
Used (used mem -buffers/cache + swap)
|
|
|
|
|
before start: 2171952
|
|
|
|
|
after start : 3544776 = 1372824 kbytes, 1340 Mbytes / 13.41 MBytes/instance
|
|
|
|
|
after kill : 2186984 = 15032 kbytes, 15 Mbytes not recovered
|
|
|
|
|
|
|
|
|
|
OK, so yes, there is more overhead. We did just start 100 Python
|
|
|
|
|
interpreters! As titled, this is dumb, and even if you use this dumb
|
|
|
|
|
method, are you really going to have a hundred of them?...
|
|
|
|
|
|
|
|
|
|
Memory use - The sensible way
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
GNOME-Terminal::
|
|
|
|
|
|
|
|
|
|
gnome-terminal &
|
|
|
|
|
for i in {1..100} ; do gnome-terminal & done
|
|
|
|
|
|
|
|
|
|
root@pinpoint:~# sync && echo 3 > /proc/sys/vm/drop_caches && free # Before 100
|
|
|
|
|
total used free shared buffers cached
|
|
|
|
|
Mem: 3102404 1490996 1611408 5344 172 47580
|
|
|
|
|
-/+ buffers/cache: 1443244 1659160
|
|
|
|
|
Swap: 3121996 749776 2372220
|
|
|
|
|
root@pinpoint:~# sync && echo 3 > /proc/sys/vm/drop_caches && free # After 100
|
|
|
|
|
total used free shared buffers cached
|
|
|
|
|
Mem: 3102404 1878228 1224176 5344 172 47388
|
|
|
|
|
-/+ buffers/cache: 1830668 1271736
|
|
|
|
|
Swap: 3121996 733396 2388600
|
|
|
|
|
root@pinpoint:~# sync && echo 3 > /proc/sys/vm/drop_caches && free # After kill
|
|
|
|
|
total used free shared buffers cached
|
|
|
|
|
Mem: 3102404 1491888 1610516 4840 272 46088
|
|
|
|
|
-/+ buffers/cache: 1445528 1656876
|
|
|
|
|
Swap: 3121996 733240 2388756
|
|
|
|
|
|
|
|
|
|
Used (used mem -buffers/cache + swap)
|
|
|
|
|
Before start: 2193020
|
|
|
|
|
After start : 2564064 = 371044 kbytes, 362 Mbytes / 3.59 MBytes/instance
|
|
|
|
|
After kill : 2178768 = −14252 kbytes, -13.92 Mbytes recovered (first process)
|
|
|
|
|
|
|
|
|
|
Terminator GTK2::
|
|
|
|
|
|
|
|
|
|
terminator -g deletemeconfig &
|
|
|
|
|
for i in {1..100} ; do terminator -g deletemeconfig -u & done
|
|
|
|
|
|
|
|
|
|
root@pinpoint:~# sync && echo 3 > /proc/sys/vm/drop_caches && free
|
|
|
|
|
total used free shared buffers cached
|
|
|
|
|
Mem: 3102404 1324492 1777912 4388 152 49688
|
|
|
|
|
-/+ buffers/cache: 1274652 1827752
|
|
|
|
|
Swap: 3121996 744528 2377468
|
|
|
|
|
root@pinpoint:~# sync && echo 3 > /proc/sys/vm/drop_caches && free
|
|
|
|
|
total used free shared buffers cached
|
|
|
|
|
Mem: 3102404 1652112 1450292 4756 860 49968
|
|
|
|
|
-/+ buffers/cache: 1601284 1501120
|
|
|
|
|
Swap: 3121996 744224 2377772
|
|
|
|
|
root@pinpoint:~# sync && echo 3 > /proc/sys/vm/drop_caches && free
|
|
|
|
|
total used free shared buffers cached
|
|
|
|
|
Mem: 3102404 1305376 1797028 4236 124 42836
|
|
|
|
|
-/+ buffers/cache: 1262416 1839988
|
|
|
|
|
Swap: 3121996 744116 2377880
|
|
|
|
|
|
|
|
|
|
Used (used mem -buffers/cache + swap)
|
|
|
|
|
before start: 2019180
|
|
|
|
|
after start : 2345508 = 326328 kbytes, 319 Mbytes / 3.16 MBytes/instance
|
|
|
|
|
after kill : 2006532 = −12648 kbytes, -12.35 Mbytes recovered (first process)
|
|
|
|
|
|
|
|
|
|
Terminator GTK3::
|
|
|
|
|
|
|
|
|
|
Not possible at the moment because the DBus interface still needs fixing.
|
|
|
|
|
|
|
|
|
|
So that one surprised me a bit. The fact that when using the single
|
|
|
|
|
process we are **more** memory efficient. Python + 100 terminals is
|
|
|
|
|
using <90% of the GNOME-Terminal + 100 terminals.
|
|
|
|
|
|
|
|
|
|
Some may think that this is something to do with the different version
|
|
|
|
|
of the VTE widget, but hang on a second. In the dumb method GTK2
|
|
|
|
|
Terminator used **more** memory than GTK3. Once the DBus is fixed for
|
|
|
|
|
GTK3 there could potentially be more savings.
|
|
|
|
|
|
|
|
|
|
"Python sucks!"
|
|
|
|
|
~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Yeah, whatever. The fact is that I'm a helluva lot more productive in
|
|
|
|
|
Python than I ever was, am, or will be, in C. In my totally biased
|
|
|
|
|
and uninformed opinion, I also think certain things are *much* easier
|
|
|
|
|
to get working in Python because you can iterate faster. With the
|
2015-08-08 04:27:53 +00:00
|
|
|
|
:ref:`debugging` option to run an interactive terminal you even
|
2015-08-08 02:11:30 +00:00
|
|
|
|
have the ability to try out ideas and explore the running instance
|
|
|
|
|
directly. Results don't get more immediate than that!
|
|
|
|
|
|
|
|
|
|
In summary
|
|
|
|
|
~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
It's a bit slower on startup, it takes a bit more memory, but that's
|
|
|
|
|
when you use the dumb method. In normal use, where you're likely to
|
|
|
|
|
be using the existing process to open a new window, it is for all
|
|
|
|
|
practical purposes as fast as the compiled GNOME-Terminal. It may
|
|
|
|
|
even (according to the last memory section) be a little lighter
|
|
|
|
|
memory wise, and more obliging about giving it back!
|
|
|
|
|
|
|
|
|
|
I didn't compare to things like xterm, because frankly we're not
|
|
|
|
|
aimed at the same people. Personally I'd rather have the more
|
|
|
|
|
extensive features saving me *lots* of time over the course of the
|
|
|
|
|
day when using it, than save a handful of seconds every few days
|
|
|
|
|
when I restart it, or worrying about an extra 5 or 10 MBytes.
|
|
|
|
|
|
|
|
|
|
-----------
|
|
|
|
|
How do I...
|
|
|
|
|
-----------
|
|
|
|
|
|
|
|
|
|
...make Terminator work like Quake style terminals?
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
You can get close, but it isn't a perfect recreation, as Terminator
|
|
|
|
|
was not designed with this in mind, but improvements are always welcome!
|
|
|
|
|
|
|
|
|
|
- Window state: Hidden
|
|
|
|
|
- Always on top: On
|
|
|
|
|
- Show on all workspaces: On
|
|
|
|
|
- Hide on lose focus: On
|
|
|
|
|
- Hide from taskbar
|
|
|
|
|
- Window borders: Off (use ``Alt``\ +\ ``click-drag`` and
|
|
|
|
|
``Alt``\ +\ ``right-click-drag`` to position and size window.)
|
|
|
|
|
- Set the Toggle window visibility shortcut to your preference
|
|
|
|
|
|
|
|
|
|
.. note:: It must be the first Terminator instance started, because
|
|
|
|
|
at present only the first instance can bind to the Window
|
|
|
|
|
toggle.
|
|
|
|
|
|
|
|
|
|
This will give you a terminal hidden at startup that appears with a
|
|
|
|
|
keypress and disappears, either with another keypress, or losing focus.
|
|
|
|
|
It will stay on top, and appear on whichever workspace you are on.
|
|
|
|
|
|
|
|
|
|
Something that we don't have is the slide in action of a true Quake
|
|
|
|
|
style terminal. The terminal will simply flick into view, and flick
|
|
|
|
|
out of view.
|
|
|
|
|
|
|
|
|
|
.. warning:: The Hide on lose focus option is problematic at this
|
|
|
|
|
time. You will probably find it very frustrating.
|