Open wbthomason opened 3 years ago
Note that this is slightly different (and easier?) than #4 (or https://github.com/tjdevries/nlua.nvim/issues/1), which is about a general-purpose run-time Lua profiler.
@wbthomason
Norcallis WIP solution works, if one calls it for the current file (it wraps all setup
functions or functions you tell it in the current file it was called). Take not that we would get an accuracy of about a few 100 nanoseconds.
One could use parts of the profiler by charlesmallah for a more pretty output.
It would be relative easy to adapt in the absence of plugin
files/vimscript files invoking lua.
However, for example the treesitter template uses this kind of annoyance. my issue on this.
Maybe this should be reformulated to something like "fix all lua setup functions to be user-defined with .setup{}
" or from packer;-) and use the Norcallis WIP solution? Or what are the additional requirements?
I dont see how to make this work easily between vimscript and lua (to put into neovim core), when you can have many places to look where to start and stop profiling the startup...
I will ask TJ about this, because the treesitter plugin template uses the setup function inside folder plugin
(invoked by vimscript).
Per some ideas discussed with @akinsho, I've made a prototype of a feature for packer
that profiles your packer_compiled
file and is Lua-aware at a high level, at least. Still WIP, but may be of interest to some people here: https://github.com/wbthomason/packer.nvim/pull/221
Just wanted to add that the profiler in packer
is merged now and works well. But before you jump into it and get confused: It will only profile Lua code that is run by packer, not by code in your init.vim
/init.lua
! So if you want to profile a Lua plugin startup, you must require
it via the config
key even if it is a start
plugin:
use {
'plugin',
config = function() require 'plugin' end
}
Also, https://github.com/neovim/neovim/pull/14788 will include Lua files sourced from plugin/
etc. in --startuptime
, going far towards closing this issue.
(It still doesn't list modules require
d from your config, though.)
I don't think https://github.com/neovim/neovim/pull/14788 could be called lua profiler. As it only profiles when a lua file is sourced . There are many other wqys to load a lua module (require
, :luafile
, dofile
, loadstring
) those will go unnoticed there . But this can probably be closed Norcallis profiler does a decent job .
@clason if you're in mood of closing close #3 . We have too many statuslines :P
I don't think neovim/neovim#14788 could be called lua profiler. As it only profiles when a lua file is sourced . There are many other wqys to load a lua module (
require
,:luafile
,dofile
,loadstring
) those will go unnoticed there . But this can probably be closed Norcallis profiler does a decent job .
Yeah, that's why I did not write "closes this issue" ;) But I think we are close to feature parity with vimscript --startuptime
now. (I thought about mentioning require
in your PR but decided against it since that would take this too far.)
For the record, a general Lua profiler is a separate wish: https://github.com/nvim-lua/wishlist/issues/4
@clason if you're in mood of closing close #3 . We have too many statuslines :P
I still haven't moved away from lightline (waiting for expressline, hint hint ;)), but that's a fair point :)
i need something like this but it can run on CI and create an image profile a profiler should calculate async load use vim.defer and schedule_wrap
What? The existing common startup time profilers https://github.com/dstein64/vim-startuptime and https://github.com/tweekmonster/startuptime.vim do not report timing information for Lua files. This would be helpful to have.
Why? Startup timing information that includes Lua files in the time breakdown is useful for tuning one's configuration.
Potential existing implementations: Building off of one of the common startup time profilers could be useful.
*Potential pitfalls:* This seems like it may require changes to Neovim's built-in startup time profiling, to ensure that Lua files are included in the output. I think that the common profiling plugins just parse this output, so it's plausible that simply augmenting the output would allow them to include Lua timing without modification.