Sublime Forum

Add lazy-loading feature of plugin?

#1

Can sublime add lazy-loading feature of plugin?
e.g. loading different plugin according to file type…

1 Like
#2

+1 on this.

 

Another way I’ve thought about this is to add a layer to the ignored_packages functionality.

There should be an easy way to temporarily [ enable | disable ] packages via syntax-specific sublime-settings files.

 

EG:
##@ Python.sublime-settings

{
	"syntax_enabled_packages":
	[
		"package_1",
		"package_2",
	],

	"syntax_disabled_packages":
	[
		"package_3",
		"package_4",
	],
}

 

Then a listener could be implemented to handle the [ activation | deactivation ] of plugins based on active file syntax.

ignored_packages would be the base which applies to all files, but the syntax_enabled|disabled_packages settings would take precedence while active.

IE: all [ ignored_packages | active packages ] would function as usual, unless specifically overridden

0 Likes
#3

This would be difficult since plugins integrate with the single Python runtime in the plugin_host process. Here are some reasons it would be difficult to pull off:

  1. Python uses a global module namespace, so unloading modules isn’t really very easy and isn’t explicitly supported by Python itself. There are hacks, but they are hacks.
  2. Threads can be running plugin code, so even if it is disabled, you can’t necessarily stop background threads running plugin code.
  3. There would be a noticeable lag when switching between different file types as different plugins with unloaded or loaded into memory.

It isn’t really even possible to do this per window since the plugin_host is shared between all open windows/projects.

May I ask what you are trying to overcome by disabling packages only some of the time?

1 Like
#4

The reason why I think this is useful is like this :slightly_smiling::

I have installed many plugins for different type of files, and it would certainly need more loading time. However, some type of files are seldom used, and the plugins for supporting these type of files have to be loaded every time.

Indeed, I can disable these plugins, and enable them again before I need them. However, lazy-loading according to file type might be a better solution. :grin::grin:

0 Likes
#5

Loading extra syntax definitions or snippets should not affect speed. Generally, performance is only affected by plugins (Python) doing things that take a lot of time in callbacks that are executed when a document is edited, or the command palette opened, etc.

The only “solution” I could see to something like this would perhaps be a package that allows quickly enabling and disabling sets of packages, but it couldn’t really be done well automatically. Additionally, it may cause error dialogs if files are in use when the package is disabled.

1 Like
#6

It would be nice to have for some of the more resource-intense plugins like ColorHighlighter and BracketHighlighter.

I’ve noticed lag while using either ( on mid-to-large sized files ).

I might only want to use ColorHighlighter while working with CSS or HTML, and I might only want to use BracketHighlighter while working with something super structure-dependent like XML.

Some plugins offer an array @ sublime-settings to choose [ enabled | disabled ] file extensions, but it would be easier to manage per syntax than per plugin.

I get what you’re saying about the difficulty of implementing it though. We’re just being lazy ( see: thread title )

1 Like
#7

BracketHighlighter does not execute on the entire file by default. It only executes on a window within that file. It should be fine in large or small files. The default threshold for that window is rather conservative and small by default.

0 Likes
#8

I bumped up the default by… a considerable amount :grin:

I run into the same issue with one of my plugins @ like 10k + lines

0 Likes
#9

FWIW, there are 2 packages that do something similar (automatically en- oder disabling packages), but I’m on mobile and won’t see an actual pc in the next days.

Iirc one was named “package bundler” and the other one I only reviewed recently (like a week ago).

0 Likes
#10

I think I use 10 thousand on my systems, but performance will differ from machine to machine.

I’m okay with user induced performance issues as long as they know it’s user induced :).

1 Like
#11

Package Bundler seems legit, it can switch plugin groups manually via the command palette or automatically via project settings.   Shouldn’t be too difficult to implement syntax or file-extension specific loading also.

It’s pretty cool that you can use it to create arbitrary plugin groups.   I can see that being useful for something like linting, which I usually keep off for performance reasons.   It would be super easy to switch on with a “Debug” profile on Package Bundler.

I still feel like the subtractive method of ignored_packages is awkward to use in this context.   It’s a lot easier to pick which plugins you do want enabled, vs the ones you don’t.

Although I’m guessing an additive method wouldn’t bee too hard to implement either.   Maybe run a loop on all installed packages, adding them to ignored_packages if no values from an enabled_packages array are matched.

@FichteFoll def post the other one if you remember or come across an actual PC :slightly_smiling:

0 Likes
#12

I can only take responsibility for about 2% of that.

The other 98% is usually Android Studio hogging all my resources

GRAAAADLE!?!!! :rage: :grimacing: :sob:

0 Likes
#13

That’s the point.
This lazy-loading feature should be handled by sublime itself rather plugins individually. :grin:

0 Likes