Slow gf caused by bootstrap

[jbarber]

First off, thank you so much for your work on vim-rails and your other vim plugins, I use them every day and they are delightful.

My issue was that gf was taking a long time to open files under the cursor (~5 seconds).

I did some digging with the vim profile tool, and it seemed like a lot of time was being spent looking for where the symbols under the cursor were defined:

FUNCTIONS SORTED ON TOTAL TIME
count     total (s)      self (s)  function
    1   5.487522170   0.002888774  rails#ruby_cfile()
    1   5.484488031   0.002694210  <SNR>134_ruby_cfile()
    1   5.476776309   0.000062306  <SNR>134_file_for_nested_constant()
    1   5.476649661   0.006508726  <SNR>134_find_file()
   89   5.470167458                <SNR>134_fcall()
   28   5.468946036   0.000154136  <SNR>134_glob()
   13   0.050444504   0.001827695  <SNR>134_app_projections()
    1   0.044858805   0.001146005  <SNR>3_SynSet()
   78   0.044782342   0.014131026  <SNR>134_combine_projections()
    7   0.035361800   0.000082813  <SNR>134_readable_projected()
    7   0.035278987   0.004994298  <SNR>134_readable_projected_with_raw()
  572   0.030651316   0.029774092  <SNR>134_extend_projection()
    6   0.030527594   0.000166066  <SNR>49_highlight()
    1   0.028093838   0.002450657  <SNR>9_LoadFTPlugin()
    1   0.024417006   0.000372251  rails#ruby_setup()
    1   0.019641749   0.002804036  rails#buffer_setup()
   63   0.015118756   0.003913869  <SNR>113_Heartbeat()
    7   0.011204887                HTTPPostJson()
    2   0.009919861   0.000152789  <SNR>134_readable_controller_name()
    2   0.009464291   0.000902163  <SNR>134_readable_find_affinity()

FUNCTIONS SORTED ON SELF TIME
count     total (s)      self (s)  function
   89                 5.470167458  <SNR>134_fcall()
  572   0.030651316   0.029774092  <SNR>134_extend_projection()
   78   0.044782342   0.014131026  <SNR>134_combine_projections()
    7                 0.011204887  HTTPPostJson()
    1   0.009436458   0.009418855  ctrlp#utils#writecache()
  157   0.007699817   0.006728058  <SNR>8_run_syntax_fold()
    1   5.476649661   0.006508726  <SNR>134_find_file()
    7   0.035278987   0.004994298  <SNR>134_readable_projected_with_raw()
   63   0.015118756   0.003913869  <SNR>113_Heartbeat()
   39                 0.003334525  <SNR>134_match_cursor()
    1   5.487522170   0.002888774  rails#ruby_cfile()
    1   0.019641749   0.002804036  rails#buffer_setup()
    1   5.484488031   0.002694210  <SNR>134_ruby_cfile()
    1   0.028093838   0.002450657  <SNR>9_LoadFTPlugin()
 1300                 0.002444092  rails#lencmp()
  101   0.002988623   0.002250676  <SNR>134_app_has()
   18   0.002289014   0.002199164  <SNR>134_define_navcommand()
   13   0.050444504   0.001827695  <SNR>134_app_projections()
   25   0.003069726   0.001538248  <SNR>134_buffer_name()
    1   0.044858805   0.001146005  <SNR>3_SynSet()

I then used strace to show the system calls vim was making when I used gf - and discovered it was making many calls to openat / newfstatat to paths under tmp/cache/bootsnap-compile-cache .

After I removed my project's tmp directory with rails tmp:clear - gf became much snappier.

I don't know if this behaviour of searching tmp is expected or is caused by something I have might have in my environment, so this might just something silly I've done.

vim --version: VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Sep 22 2023 00:00:00)
ruby --version: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]
vim-rails version: 1ad9663