terminator/doc/manual/source/faq.rst

275 lines
11 KiB
ReStructuredText
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

.. 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
:ref:`debugging` option to run an interactive terminal you even
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``\ +\ ``middle-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.