[Paul M]

Would this slow execution if lots of plugins were calling lots of files ?

[The Geek]

Originally Posted by Paul M

Would this slow execution if lots of plugins were calling lots of files ?

A lot less then housing all the PHP for all files in memory at all time.

The bulk of my processing is done via external files.

[Milad]

Originally Posted by Paul M

Would this slow execution if lots of plugins were calling lots of files ?

I agree

I think files modifications would be better for this purpose

[Marco van Herwaarden]

I have been thinking about creating an extension that will allow 'include-files' for plugins. They would be loaded as regular plugins (not file uploads), and can be loaded into memory whenever needed (for example: require_pluginlibrary_once('myfunctionlibraryplugin'); ).

Like this you might get the best of both worlds:
- No file uploads
- Only loaded into memory when needed

[PennylessZ28]

I like that concept, I think I am going to play with this some more.

[99SIVTEC]

i'm ditching the plugin system on most of my larger sites. I'm just hardcoding the hacks. The plugin system is great in principal, but it eats up memory, increases queries, and slows down execution.

[PennylessZ28]

Originally Posted by 99SIVTEC

i'm ditching the plugin system on most of my larger sites. I'm just hardcoding the hacks. The plugin system is great in principal, but it eats up memory, increases queries, and slows down execution.

Oh so true. If only there was a way to use this concept of the xml plugin to also upload a file like the above. So its not stored in memory.

[Marco van Herwaarden]

Originally Posted by 99SIVTEC

i'm ditching the plugin system on most of my larger sites. I'm just hardcoding the hacks. The plugin system is great in principal, but it eats up memory, increases queries, and slows down execution.

If coded for saving memory(ie. 99% of executable code in include files), a plugin don't need to use much memory, nor does it need to use more queries or slow down significantly.

[amykhar]

Originally Posted by Brad

This is in the manual but I've yet to see it mentioned here.

I feel better now. Somebody griped when I wrote my Amazon plugin this way

[99SIVTEC]

Just having the plugin system turned on uses extra queries. A good programmer ca hack vbulletin in such a way as to add few if any extra queries, but the system itself is what adds the extra queries.

Originally Posted by MarcoH64

If coded for saving memory(ie. 99% of executable code in include files), a plugin don't need to use much memory, nor does it need to use more queries or slow down significantly.

[Marco van Herwaarden]

Originally Posted by 99SIVTEC

Just having the plugin system turned on uses extra queries. A good programmer ca hack vbulletin in such a way as to add few if any extra queries, but the system itself is what adds the extra queries.

Not sure on the exact amount of added queries when the plugin system is turned on, but it is not much, and they are good optimiyed and won't effect your board much from a performance point of view.

Remember that the number of queries is almost irrelevant for performance, it is the execution time that counts.

[PennylessZ28]

Seems to me that just putting the plugin code in a php file and replacing it with

include('./plugins/my_script.php');

Doesn't work 100%

[Marco van Herwaarden]

Nobody ever said that things would work without any modification.

[Andreas]

1. Turning the Plugin System On or Off does not have any impact on the amout of queries.
2. Memory Footprint is not a such a big issue. In most cases, forumcache (which is loaded on every page) for example will be a lot bigger then the plugins.

Having to eval() the code all the time, that is an issue.

Therefore, complex plugin code (especially in high-traffic places like global.php, postbit, showthread, forumdisplay, etc.) should be moved out to include files.
(Could even be done automatically. I wrote a proof-of-concept hack that writes include-files if the plugin-code on one hook is > X bytes long.)