Delay on first press

[amerlyq]

After starting vim, pressing on /?nN*# launches <Plug>(incsearch-* which innards involve too much magic and causes delay.
It's only 0.6s and would be unnoticed if you work long with same copy of vim.
But when exploring big tree of sources (like kernel sources) -- in my case using ranger and vim in urxvt, each copy of vim lives only 10-15s. And I feel this delay as eternity before search.

Could time consuming operations be moved to plugin file loaded on startup with everything else, so this delay affected vim startup time instead of first press on search?

[haya14busa]

I implemented incsearch#preload() at this branch https://github.com/haya14busa/incsearch.vim/tree/incsearch-preload

Could you please trying this branch with below config in your vimrc?

call incsearch#preload()

[amerlyq]

Done. Delay is really moved to vim startup time, so it could be valid option to toggle preloading (however, neobundle lazy loading is more consistent). Here piece of my profiling, related to incsearch-preload, sorted by total time:

0.010881  0.000096      20    vital#_incsearch#new()
0.011177  0.002646      43    <SNR>35__get_functions()
0.016974  0.016974      2     <SNR>249_uniq_by()
0.017088  0.000114      2     <SNR>249_uniq()
0.024155  0.000841      40    <SNR>35_search()
0.025764  0.001609      40    <SNR>35_expand_modules()
0.026603  0.000510      3     <SNR>202_init()
0.058364  0.001127      2     381()
0.102108  0.102108      3450  <SNR>35__unify_path()
0.416896  0.001403      45    <SNR>35_import()

But I have one more result:
If I will NOT include 'call incsearch#preload()' into configs, startup time remains instant BUT loading time 'on_press' is reduced almost twice. May it be you have optimized code? Could that optimization be done farther to eliminate necessary in such preloading or make it preload permanent?

Here could exist compromise -- split initialization (and loading time) to 'startup' and 'on_press' pieces, each of them will consume only bearable time. However, algorithms optimizing would be best. Maybe applying somewhat granular profiling for specific functions? Or there is some kind of linewise profiling for vim...

[haya14busa]

Thanks for the measuring.

I updated vital.vim (the library incsearch.vim internally depends on) in the dev branch and there are some commits to optimize loading time, so it may reduce loading time more :)

BUT loading time 'on_press' is reduced almost twice

I didn't measure it but I guess both my refactoring and the library update reduce the loading time.

split initialization

Actually, the too-long loading time is depends on environment.
vital.vim's loading time take long time for some environment like windows.
So, I do not want to split initialization but I hope above optimization is enough.

[amerlyq]

To complete that note, environment for profiling -- Linux Mint, i5 (dual core), HDD :))
I'm looking forward for merging current optimizations in master. Thanks.

[haya14busa]

I merged dev branch into master. Could you please giving it a shot?

[amerlyq]

Checked. You greatly optimized code -- first press on * # feels like instant.
And even delay for / ? has reduced -- till 0.3s, which is rather satisfiable.
Or maybe it could be even better? :)
Nevertheless, I will post my profiling for / ? press delay (previous was for * # only) -- maybe you could figure out where to optimize more. Now functions are sorted by their own time:

0.263352  0.001319   45   <SNR>205_import()
0.001533  0.001533   299  <SNR>213__compare()
0.018414  0.001697   40   <SNR>205_expand_modules()
0.001762  0.001762   40   <SNR>205__file2module()
0.023562  0.002662   43   <SNR>205__get_functions()
0.025696  0.003190   5    149()
0.012369  0.003445   2    vital#of()
0.028174  0.026393   31   181()
0.029915  0.027784   82   <SNR>205__vital_files()
0.035893  0.035893   4    <SNR>198_uniq_by()

[haya14busa]

Sorry for the late response.

Thank you for the profiling and now delay for / ? has reduced, is this issue closable?
Of cource, I want to optimize it more, but I don't have any idea to optimize it further more right now.

[amerlyq]

Aah, yes, it's no problem now. Thanks.

[haya14busa]

Thanks. I'll keep improving it!