Slow startup

[diggit]

Hi,
I noticed, that tym startups are slow (and maybe getting gradually slower?)
Here is comparison with urxvt:

# time urxvt -e "bash -c exit"                                                                                                                                                                                                      2019-08-18T11:20:42 CEST
0.03user 0.01system 0:00.04elapsed 95%CPU (0avgtext+0avgdata 13424maxresident)k
0inputs+0outputs (0major+1055minor)pagefaults 0swaps

# time tym -e "bash -c exit"                                                                                                                                                                                                        2019-08-18T11:20:47 CEST
0.18user 0.05system 0:00.25elapsed 91%CPU (0avgtext+0avgdata 40592maxresident)k
1824inputs+0outputs (5major+4956minor)pagefaults 0swaps

200 ms might be ok for some users, but I spawn terminals in tiling wm (i3) pretty often. Slow startup causes, that tym misses several keystrokes when start typing immediately after launching tym (with kb shortcut).

Using Arch Linux, tym version 2.2.1.

EDIT:

under heavy CPU load:

# time tym -e "bash -c exit"                                                                                                                                                                                                        2019-08-18T12:04:34 CEST
0.36user 0.05system 0:00.50elapsed 84%CPU (0avgtext+0avgdata 40948maxresident)k
0inputs+0outputs (0major+4970minor)pagefaults 0swaps

# time urxvt -e "bash -c exit"                                                                                                                                                                                              506ms  2019-08-18T12:04:37 CEST
0.04user 0.01system 0:00.06elapsed 88%CPU (0avgtext+0avgdata 13448maxresident)k
0inputs+0outputs (0major+1009minor)pagefaults 0swaps

[endaaman]

Hello @diggit

Thank you for reporting. I think this is because tym uses Lua for configuration. When starting up, tym needs to initialize Lua context, parse config Lua script, run it and apply aggregated values to the app. Some of the procedures might be slow. Or tym depends on GTK and GTK might be potentially slower than bare X11.

In any case, I'm not sure which makes tym slow. I need some time to investigate the reason. Feel free to let me know if you have anything other.

[diggit]

I don't know how to analyze it. For start, I tried to remove config and theme files. I found another problem this way...

# time tym -e "bash"                                                                                                                                                                                                  
** Message: 19:53:23.649: Config file (`/home/diggit/.config/tym/config.lua`) does not exist. Skipped config loading.
** Message: 19:53:23.649: Theme file (`/home/diggit/.config/tym/theme.lua`) does not exist. Skiped theme loading.

and tym keeps running with my default shell which is fish, entirely ignoring -e option. This option behaved normally with config file present. Probably bug?

[endaaman]

I'm sorry. It is a kind of bug that option is not applied when config is not loaded. I have fixed at 42b243c and released 2.3.0. You can get the new version from AUR now.

[TorchedSammy]

i'd really like for this to be investigated since my only complaint about tym is 1st time startup being slow, ranging in multiple seconds, but after is similar speeds to whats shown below

and for reference (hyperfine is a better benchmarking tool)

~                                                                               
∆ hyperfine --warmup 3 "tym -e \"sh -c exit\""
Benchmark #1: tym -e "sh -c exit"
  Time (mean ± σ):     962.7 ms ±  44.3 ms    [User: 640.1 ms, System: 182.9 ms]
  Range (min … max):   909.2 ms … 1071.8 ms    10 runs

[dacyberduck]

I think this is because tym uses Lua for configuration. When starting up, tym needs to initialize Lua context, parse config Lua script, run it and apply aggregated values to the app. Some of the procedures might be slow.

How about a server - client mode.. can be useful in this context. During starting the server, tym have to parse the lua configs only once and then spawning the clients will be much faster.

[endaaman]

tym is supporting server-client mode now. When you start tym at first, the instance becomes a primary instance. Then, if you start another an instance, the process will stop immediately instead of spwaning a new window on the primary process.
The first spawn would be still slow, but the second will be faster because of no need to initialize GTK application footprint. However there is still a need to initialize new Lua context so that each instance needs to have different one.

First time:

~ $ time tym -e 'sh -e exit'
** Message: 15:32:26.400: [id=0] Started.
** Message: 15:32:26.401: [id=0] Theme file `/home/ken/.config/tym/theme.lua` doesn't exist.
** Message: 15:32:26.402: [id=0] Config file `/home/ken/.config/tym/config.lua` loaded.
** Message: 15:32:26.402: [id=0] DBus: object_path='/me/endaaman/tym0' interface_name:'me.endaaman.tym'
** Message: 15:32:26.462: [id=0] Quit.
tym -e 'sh -e exit'  0.09s user 0.01s system 87% cpu 0.118 total

Second time:

~ $ time tym -e 'sh -e exit'
tym -e 'sh -e exit'  0.01s user 0.01s system 80% cpu 0.021 total

The log of the second spawn will be printed on the primary instance.

[Stardust-kyun]

From my experience it would be best to have a daemon mode similar to the one urxvt has, that way you don't need to rely on a client already being open for fast startup. Not sure if that's viable but it would be a great addition.

[erikLundstedt]

From my experience it would be best to have a daemon mode similar to the one urxvt has, that way you don't need to rely on a client already being open for fast startup. Not sure if that's viable but it would be a great addition.

this sounds really great if I haven't misunderstood something
the way I understood this, I would be able to put tym-nogui(or something similar) in my windowmanagers autostart section and then have tym start really quickly each time I run tym because it only has to do lua and gtk/gui stuff when starting that way

this would be something like runing a tui app in tmux/screen or like using emacs-daemon/emacs-client

I've had some issues with startup-times on one of my machines, but only on first run and would LOVE to have them fixed as I really enjoy the program

[endaaman]

@Stardust-kyun @erikLundstedt
OK. I understand the demands. I will work on adding the server mode like such as tym --daemon and a systemd service to spawn it. Though I'm a bit busy at my job these days and don't know when it will be completed, please wait for it.

[Stardust-kyun]

No rush! Glad to hear it's planned, I'm really loving tym so far :)

[erikLundstedt]

@Stardust-kyun @erikLundstedt
OK. I understand the demands. I will work on adding the server mode like such as tym --daemon and a systemd service to spawn it. Though I'm a bit busy at my job these days and don't know when it will be completed, please wait for it.

Thank you greatly

I currently use tym as a secondary terminal emulator as I am usually a heavy tab-user (I use wezterm as my main one, and am loving it aswell).
As I said I only get the slowness on my home PC but not at work (booth very similar Arch installs)

Take the time you need to implement it without getting burnout.

I really appreciate the work you have done and I always love to see more stuff be configurable in Lua (or in my case, fennel lisp ) as it's one of my favourite programming languages

[endaaman]

I have pushed #90 and started implementation. This feature was fortunately easy to be realized. I'm planning to add user-level systemd unit. Requests will be accepted on the PR thread.

This feature will be contained in the next release.

[TorchedSammy]

🔥🔥 hell yea I'll try this out when I get home

[endaaman]

--daemon option has been added on the latest release. Please try this.

[Stardust-kyun]

Currently using it, appears to be working smoothly so far!

[erikLundstedt]

@endaaman
this should (probably) be closed

on my system:
(using hyperfine as suggested by @TorchedSammy)

tym (tym-git from the aur)

$ systemctl start --user tym-daemon.service
$ hyperfine --warmup 3 'tym -e "sh -c exit"'
Benchmark 1: tym -e "sh -c exit"
  Time (mean ± σ):     134.0 ms ±  10.1 ms    [User: 13.8 ms, System: 5.2 ms]
  Range (min … max):   125.4 ms … 163.4 ms    19 runs
$ systemctl stop --user tym-daemon.service
$ hyperfine --warmup 3 'tym -e "sh -c exit"'
Benchmark 1: tym -e "sh -c exit"
  Time (mean ± σ):     282.8 ms ±  10.7 ms    [User: 200.1 ms, System: 28.8 ms]
  Range (min … max):   265.2 ms … 299.5 ms    10 runs

compared to my "main" terminal, which is known to be fast, is written in rust,configured in lua, and is "GPU assisted"...
wezterm (wezterm-git from the aur) wezterm

Benchmark 1: wezterm start --always-new-process sh -c exit
  Time (mean ± σ):     253.6 ms ±  16.7 ms    [User: 47.0 ms, System: 35.5 ms]
  Range (min … max):   228.7 ms … 284.2 ms    11 runs

compared to miniterm
this is probably the one that is the most similar to tym in features, its written in C and uses vte3, just like tym, no lua config though and it haven't had an update in a few years
(miniterm (not -git) from the aur)

hyperfine --warmup 3 'miniterm -e "sh -c exit"'
Benchmark 1: miniterm -e "sh -c exit"
  Time (mean ± σ):     194.4 ms ±   9.3 ms    [User: 125.6 ms, System: 24.2 ms]
  Range (min … max):   181.9 ms … 211.3 ms    14 runs

and lastly, compared to alacritty
(alacritty (not -git) from the aur)

hyperfine --warmup 3 "alacritty -e sh -c exit"
Benchmark 1: alacritty -e sh -c exit
  Time (mean ± σ):     152.4 ms ±  10.2 ms    [User: 60.5 ms, System: 45.4 ms]
  Range (min … max):   132.5 ms … 167.4 ms    18 runs