Linked binary opening slower than original

[kristijanhusak]

Hi,

with the recent update to 2.9.1 (or maybe 2.9.0, I'm not sure), I started noticing that my Neovim is starting slower. I started checking out what's happening and noticed that ~/.local/share/bob/nvim-bin/nvim binary is not a symlink to the downloaded binary in ~/.local/share/bob/nightly/nvim-linux64/bin/nvim (or any other stable version). When I tried to execute the binary directly, the startup time was normal. Then I tried to delete ~/.local/share/bob/nvim-bin/nvim and create a symlink to ~/.local/share/bob/nightly/nvim-linux64/bin/nvim on the same place and everything worked fine. Seems that nvim binary that is generated in nvim-bin is somehow slower, but I can't figure out why.

Here's a short gif showing the difference, but unfortunately it's barely noticeable like this. I notice it when I open:

I also tried downgrading bob to 2.8.3, and with it I don't notice the slowness, even though nvim-bin/nvim is also not a symlink on this version.

OS: Arch Linux Bob version: 2.9.1 (Downloaded from AUR) Neovim version: Probably all of them, tested with 0.9.2, 0.9.5, nightly.

[JMarkin]

I have this problem too. more info if use bob's nvim

/usr/bin/time -v ~/.local/share/bob/nvim-bin/nvim -u NONE --headless -c ":q" Command being timed: "/home/kron/.local/share/bob/nvim-bin/nvim -u NONE --headless -c :q" User time (seconds): 0.17 System time (seconds): 0.64 Percent of CPU this job got: 212% Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 0.38s Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 31488 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 1607 Minor (reclaiming a frame) page faults: 7055 Voluntary context switches: 16615 Involuntary context switches: 1125 Swaps: 0 File system inputs: 679 File system outputs: 332 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0

and native

/usr/bin/time -v /usr/local/bin/nvim -u NONE --headless -c ":q" Command being timed: "/usr/local/bin/nvim -u NONE --headless -c :q" User time (seconds): 0.00 System time (seconds): 0.02 Percent of CPU this job got: 100% Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 0.03s Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 36864 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 2400 Voluntary context switches: 2 Involuntary context switches: 2 Swaps: 0 File system inputs: 676 File system outputs: 334 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0

[MordechaiHadad]

Ye unfortunately it is slightly slower cuz bob now auto-updates the proxy which it does by checking the parent process is bob and then it will print bob version https://github.com/MordechaiHadad/bob/blob/master/src/main.rs#L86

The question is how impactful is this slowdown when actually working? Also I am open for other solutions instead of the current one.

[kristijanhusak]

It's fairly noticeable for me. At moments it feels like it needs between 0.5 - 1 sec to open. I'm not sure what is the exact purpose of auto-proxy, but whatever was happening with v2.8.3 was working fine or just doing a regular symlink works. It would be ok if it's an opt-in through config.

[MordechaiHadad]

Auto proxy just basically stops the proxy to break on some specific releases so it auto updates itself, an opt in symlink could be cool probably for Unix people.

[MordechaiHadad]

I had another idea instead of having symlink opted in which will add it's own complexity. My idea is either have bob proxy check for ENV VAR called something which bob will create everytime on use, or another idea is bob will pass --bob which the proxy will check and if it finds it, it will do the auto update thing.

If you have other suggestions go ahead.

[kristijanhusak]

another idea is bob will pass --bob which the proxy will check and if it finds it, it will do the auto update thing

Does this mean that the proxy check will happen only when switching versions? If yes, I vote for this option.

[MordechaiHadad]

another idea is bob will pass --bob which the proxy will check and if it finds it, it will do the auto update thing

Does this mean that the proxy check will happen only when switching versions? If yes, I vote for this option.

It always only happens when switching versions but the proxy checks currently if parent process that spawned it is bob which causes this slowness, something like checking the first argument as --bob could be much faster.

[MordechaiHadad]

Alo @kristijanhusak feel free to check this new PR

Just: bob use nightly see if it prints that it updated proxy, and run neovim as usual.

[kristijanhusak]

I'm getting panic. Here's full stacktrace:

╰─ RUST_BACKTRACE=full nvim                                                                                                                                                                                                                  ─╯
thread 'main' panicked at src/main.rs:78:12:
index out of bounds: the len is 0 but the index is 0
stack backtrace:
   0:     0x55a174748aa5 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h01ae9338a6ae91eb
   1:     0x55a174777423 - core::fmt::write::h491257998796a622
   2:     0x55a17474538f - std::io::Write::write_fmt::hb2c64deac04aca6a
   3:     0x55a1747488b0 - std::sys_common::backtrace::print::h06f8cce91d6289fa
   4:     0x55a174749f25 - std::panicking::default_hook::{{closure}}::hcd1fdb5834ba5bf8
   5:     0x55a174749ca3 - std::panicking::default_hook::h40cebc24e84e383d
   6:     0x55a17474a3b8 - std::panicking::rust_panic_with_hook::h619a773c3e95c6fc
   7:     0x55a17474a296 - std::panicking::begin_panic_handler::{{closure}}::h991678da18466d9f
   8:     0x55a174748f99 - std::sys_common::backtrace::__rust_end_short_backtrace::h88c53d196138c39d
   9:     0x55a174749fe7 - rust_begin_unwind
  10:     0x55a174258fb6 - core::panicking::panic_fmt::h63d411b0acff0bd2
  11:     0x55a174259187 - core::panicking::panic_bounds_check::h08bca44c42519a48
  12:     0x55a1742673dd - tokio::runtime::park::CachedParkThread::block_on::h0b1e49f71dad2b37
  13:     0x55a174348bb2 - tokio::runtime::context::runtime::enter_runtime::hfcab75b08fb39ed2
  14:     0x55a174301a1e - tokio::runtime::runtime::Runtime::block_on::he26be5c2c31c53c6
  15:     0x55a174354455 - bob::main::h0062318de5785acf
  16:     0x55a174360213 - std::sys_common::backtrace::__rust_begin_short_backtrace::ha491b6a726d9b182
  17:     0x55a174336d4d - std::rt::lang_start::{{closure}}::h1a3d336ff9cdd6a1
  18:     0x55a17473d4fe - std::rt::lang_start_internal::h89fc545bf879bd54
  19:     0x55a174354535 - main
  20:     0x7935e45f3d4a - <unknown>
  21:     0x7935e45f3e0c - __libc_start_main
  22:     0x55a174259605 - _start
  23:                0x0 - <unknown>

[MordechaiHadad]

Lmao what the fuck my bad, gonna fix it rq

[MordechaiHadad]

Done @kristijanhusak

[kristijanhusak]

Seems to be working fine now.