Autoload plugins

[Chris K]

Is it really necessary to load/unload say 30-40 plugins at every Avisynth startup?
I understand Avisynth has to know what commands are in it for the actual requested options
but I think there could be more elegant (and less delaying) ways to get this.

1. Scan the plugin dir for dlls and register all commands in a small database.

2. At next runs only check if new, deleted or updated dlls exist (check date and time).
... This can be done very fast.

3. If there are changes load/unload only new/updated dlls to update the database
... and for the others use the data that's already in the database.

It's just an idea from someone who also use Avisynth for short previews of created/modified scripts.

Chris.

[2Bdecided]

When you get to that number, it makes sense to move them out of the plugins folder, and load them when needed with "Loadplugin" commands in each script. It helps keep track of which script uses what, and allows you to use different verisons of the same plugin in different scripts if needed.

Cheers,
David.

[squid_80]

Note to plugin authors: changing the base address while compiling is a freebie.

[Fizick]

note to noter: some plugin authors do not understand your mantra about base address
:)

[IanB]

Base address is a hint to the loader as to where to load this .DLL, most usefull for spotting opps's occuring in your code. i.e. Set Base Address as 0x12340000, see a crash address as 0x12340789, can reasonably assume code at offset 0x0789 in your .DLL just coughed up a lung.

Probably should do this with Avisynth.dll.

[squid_80]

What I was actually getting at is that nearly every plugin/codec/hooked-in-dll-from-god-knows-what has the default preferred base address of 0x10000000. Sections of code can't share the same address space within a process (duh) so if the preferred memory base for a dll is already in use it must be "rebased" when loaded - it ends up being loaded at a different address and all the memory references have to be corrected by the loader. Doesn't sound like a big deal but can have a significant impact in situations like the OP described. Picking any base address other than the default is advisable, just don't go too high ( > 0x70000000 is reserved for system I think) or too low ( < 0x00002000?). There's no way to guarantee you won't get a collision but chances can be greatly reduced.

IanB's reason is pretty good too, I'm far too reliant on virtualdub's crash handler to do the hard work and tell me what's fallen over and why.

[Fizick]

Thanks. The last question. How to "picking any base address other than the default"? Is it linker setting (command-line option)?

[Leak]

Is it linker setting (command-line option)?
Exactly. (http://msdn2.microsoft.com/en-us/library/f7f5138s(VS.71).aspx) :)

np: Praxis - Bent Light (Tennessee 2004)

[Chris K]

Perhaps a easier way to implement a solution to the autoload delay could be, to add a flag
that can be set at the start of a script. Something like:

AutoLoad=false
LoadPlugin("plugins_path/VSFilter.dll")

Avisynth then first would read the script and decide to process or skip the autoload procedure.

Chris.

[stickboy]

I move all the plugin DLLs out of the plugin folder. Instead, I put an .avsi file in the plugin folder that calls LoadPlugin on just the plugins I regularly use.

One could even define a function in such an .avsi file that loads different sets of plugins depending on its argument.

[IanB]

@Chris K,

The autoload plugins are parsed at CreateScriptEnvironment time. This is well before any scripts are parsed. So the damage has occured well before AutoLoad=false could be parsed and acted apon.

Your best bet is to properly manage your plugins and the autoload folder.

[Chris K]

I understand.

It's just that my application runs small scripts for color correction preview and because my application is
public, I have to deal with the fact that a lot of people copy all their plugins to the autoload plugins folder.
I know that the Avisynth manual describes the purpose of this folder very well. Perhaps there can be a link
added to a guide on how to manage the different types of dll's efficiently?

Thanks,
Chris