rose-pine/neovim

feature: start up performance

Amleto opened this issue · 8 comments

Describe the solution you'd like

Rose pine plugin load is taking ~50ms of the 70-80ms that lazy reports as the initial load time, which seems quite hefty.

I wonder if some of this is down to processing the hl groups for all possible third party plugins in the rose-pine.lua file.

I noticed that catpuccin had a kind of opt-in configuration (see integrations) where you tell the theme what TP highlight groups are needed.

This might help reduce some unnecessary startup overhead.

Additional context

No response

I tried to reproduce high startup times using lazy's builtin profiling for both the stable version of Rosé Pine and a stripped down version with only builtin vim syntax groups and the latest treesitter groups. Here's the results:

Stable

All highlight groups and features enabled

Screenshot 2024-01-22 alle 11 59 59

Stripped

Using about 1/3 of the highlight groups with less logic running per highlight

Screenshot 2024-01-22 alle 11 58 59

The startup times—on my device—are within the same millisecond. This was using the same init.lua with only treesitter and Rosé Pine installed.

Surprisingly, there isn't much of a difference, even after removing some, what I thought would be, time consuming tasks such as parsing and looking up each named color in our palette per highlight group.

Edit: This is not to say Rosé Pine isn't overly complex for what it does. I'm happy to release a version that handles things more efficiently and potentially allows disabling some categories of highlights. It would be nice, though, to have an effective way of measuring this impact while developing.

For reference, here's catppuccin on my system with the same setup:

Screenshot 2024-01-22 alle 12 14 56

Hmm, interesting. So how is the colorscheme being activated here?
I was including a vim.cmd.colorscheme() command at the end of a lazy config = function()... function.

I took the colorscheme command out and got numbers much closer to what you're seeing, so the plugin loading is fine, it's just the colorscheme command takes a while. Maybe it's just my slow computer!

This is the full config used in the screenshots above:

local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
	vim.fn.system({
		"git",
		"clone",
		"--filter=blob:none",
		"https://github.com/folke/lazy.nvim.git",
		"--branch=stable", -- latest stable release
		lazypath,
	})
end
vim.opt.rtp:prepend(lazypath)

require("lazy").setup({
	{
		"nvim-treesitter/nvim-treesitter",
		build = ":TSUpdate",
		config = function()
			require("nvim-treesitter.configs").setup({
				highlight = { enable = true },
			})
		end,
	},
	{
		"rose-pine/neovim",
		name = "rose-pine",
		lazy = false,
		priority = 1000,
		config = function()
			-- require("rose-pine").setup()
			vim.cmd.colorscheme("rose-pine")
		end,
	},
	-- { "catppuccin/nvim", name = "catppuccin", priority = 1000, config = function() vim.cmd.colorscheme("catppuccin") end }
})

Let's revisit this in a day or two once I'm able to push up some changes that may or may not address the performance and maybe it'll be more obvious on your device :)

Pushed performance improvements (hopefully!) to #217. Feel free to test out that branch–otherwise I'll merge them in a week or so if no one reports any issues.

Thanks! I switched between the branches locally but didn't see any significant difference between them. I thought it might be something specific to my machine (windows) so tried on work laptop. That is also windows but nvim is in wsl2. The perf is actually worse on laptop despite much better cpu (again, nearly all the time is from the coloscheme command).

Hmm I’ll have to dig in a little more then. Appreciate you testing! Will post any updates here when ready

If anyone comes across this, please feel free to open a PR or provide a comparison between another theme and Rosé Pine showcasing the performance difference. I'd love to discuss/improve where possible but cannot see any significant cause at the moment—I am not familiar with benchmarking lua plugins to find any bottlenecks.