Noticeable slowdowns running `tms` after upgrading to v0.5.0

[fautore]

Upgraded to v0.5.0, noticed that running tms now is very slower compared to v0.4.5.

I ran some tests with hyperfine (compiled the binaries with cargo build --release) spamming the esc key. I'm very aware that this is a very non-conclusive test, but the difference in the time took warrants some additional investigation nonetheless, here are the results:

> hyperfine ./v0.4.5
Benchmark 1: ./v0.4.5
  Time (mean ± σ):     204.3 ms ±  16.8 ms    [User: 41.1 ms, System: 163.7 ms]
  Range (min … max):   184.4 ms … 263.1 ms    16 runs

> hyperfine ./v0.5.0
Benchmark 1: ./v0.5.0
  Time (mean ± σ):     713.0 ms ±  17.3 ms    [User: 551.5 ms, System: 166.5 ms]
  Range (min … max):   672.5 ms … 730.7 ms    10 runs

> hyperfine ./v0.4.5 ./v0.5.0
Benchmark 1: ./v0.4.5
  Time (mean ± σ):     202.2 ms ±   8.0 ms    [User: 39.8 ms, System: 166.2 ms]
  Range (min … max):   182.3 ms … 214.5 ms    16 runs

Benchmark 2: ./v0.5.0
  Time (mean ± σ):     720.6 ms ±   9.5 ms    [User: 559.8 ms, System: 165.3 ms]
  Range (min … max):   703.9 ms … 732.3 ms    10 runs

Summary
  ./v0.4.5 ran
    3.56 ± 0.15 times faster than ./v0.5.0

Actual tests

Did some more digging, wrote a test that measures execution time for find_repos and ran with cargo (thereby eliminating user esc behaviour).
All the configurations are the same as the first set of tests.

v0.5.0:

> cargo test -- --nocapture
   ...(omit output for brevity)
Function execution time: 2.733594328s
test repos::test::perf_find_repos ... ok
   ...(omit output for brevity)

v0.4.5

> cargo test -- --nocapture
   ...(omit output for brevity)
Function execution time: 534.414374ms
test repos::test::perf_find_repos ... ok
   ...(omit output for brevity)

Let me know if further investigation is needed.

[junglerobba]

From looking at your test code, is your personal config using search_paths or search_dirs? It seems like search_dirs was introduced at a later point to be able to configure search depth, and search_paths are simply configured with a default depth of 10. So if your config is using paths, and some of your directories do not contain a .git directory and maybe lots of nested dirs (e.g. node_modules), then that might explain why it's slow. Though that doesn't explain why that changed with 0.5.0 🤔

[fautore]

You're right, my personal config was using search_dirs with depth 10, while the tests were using search_paths, I fixed the tests, these are the new (more correct) results:

v0.4.5

Function execution time: 183.142463ms
test repos::test::perf_find_repos ... ok

v0.5.0

Function execution time: 2.808633004s
test repos::test::perf_find_repos ... ok

The directory i'm targeting has 25 git repositories of various sizes, each one is a git repo, some have node_modules. As you suspected, the problem remains and is not tied to depth.

[fautore]

I tried to set depth to 1 and it's way faster now.
Okay, it's definitely tied to depth

Function execution time: 28.865013ms
test repos::test::perf_find_repos ... ok

[husjon]

I initially noticed the slowdown after the update but was able to get a slight improvement by reducing the depth, however as my projects folder is growing the issue just gets worse.

There are about 200 .git folders in there at various depths and sizes.
It takes about 0.9 seconds for find to list them however tmus-sessionizer uses just over 3 seconds at depth 5.

Currently I'm using the following config file:

display_full_path = true
session_sort_order = "LastAttached"

[[search_dirs]]
path = "~/projects"
depth = 5

[picker_colors]
highlight_color = "#11111B"
highlight_text_color = "#CBA6F7"
border_color = "#CBA6F7"
info_color = "#CBA6F7"
prompt_color = "#CBA6F7"

With this config, stepping back through the commits, rebuilding and testing (in a similar fashion as @fautore), I found the following results using hyperfine

0e81af4 (v0.4.5)

  Time (mean ± σ):     199.3 ms ±  23.0 ms    [User: 82.2 ms, System: 116.1 ms]
  Range (min … max):   187.6 ms … 249.0 ms    12 runs

015b34d

3 commits after v0.4.5 and last working at a reasonable speed

  Time (mean ± σ):     369.4 ms ±  60.9 ms    [User: 234.0 ms, System: 122.9 ms]
  Range (min … max):   346.6 ms … 542.4 ms    10 runs

ff6e289

Merge commit for jujutsu
Linking error:

error: linking with `cc` failed: exit status: 122.9

8be71f3

commit just after the merge commit for jujutsu updating libraries

  Time (mean ± σ):      3.165 s ±  0.146 s    [User: 3.032 s, System: 0.131 s]
  Range (min … max):    3.075 s …  3.515 s    10 runs

[husjon]

I did a little bit more testing and I should add that the default depth of 10 results in my case of a casual 55 second halt until I see the list of directories using 8be71f3, while 015b34d results in a more sane 1.8 seconds.

Depth 10 using 015b34d

  Time (mean ± σ):      1.887 s ±  0.011 s    [User: 0.866 s, System: 1.021 s]
  Range (min … max):    1.873 s …  1.908 s    10 runs

I did not do a full test of 8be71f3 because each run takes almost a minute