Personally I have not so good experience with running plugins from Folder on Windows systems.
Compressed vs. uncompressed plugin makes only a difference between disk moving more bytes vs. CPU doing more instructions.
But having them as folder structure should make an improvement as Xojo can skip writing the temp DLL files.
Where it’s making the biggest difference is in Linux in a VM. Over 80% faster on load and from 3:40 to run the initial 64 bit compile to 48 seconds.
I wonder if Xojo are using mkdtemp/mkstemp or using a roll-your-own unique temp file generator method …
Because since a few releases i also see awful long startup times, i made a FR: <https://xojo.com/issue/58748>
Your script seems to work fine.
I’ll include this one with next plugins:
[code]#!/bin/zsh
unplug.sh
A script to uncompress plugin archives to have Xojo load them faster.
be sure to chmod +x unplug.sh
called like:
./unplug.sh [path to xojo]/plugins/*
e.g.
/Users/cs/Desktop/unplug.sh /Applications/Xojo/Plugins/*
while [ -n “$1” ]
do
FILENAME=$1
if [[ ! -d “${FILENAME}” ]]
then
echo “Processing ${FILENAME}”
mv “${FILENAME}” “${FILENAME}.zip”
mkdir “${FILENAME}”
yes | unzip -d “${FILENAME}” “${FILENAME}.zip”
rm “${FILENAME}.zip” #comment this line to not delete original files
fi
shift
done
Thanks to Jim Mckay for creating the original. script.[/code]
It’s already time consuming enough to manage Plugins. I’d like to see this implemented into the IDE. 
Yes - after the first run-through, leave the resulting unpackaged versions in place instead of doing it every launch.
I just realized that Jim wrote that for zsh - which we don’t have prior to 10.14. I’m rewriting it for bash (which zsh handles properly). I’ll post in a few minutes.
Actually, changing the shebang to #!/bin/bash sorts it:
#!/bin/bash
# unplug.sh
# A script to uncompress plugin archives to have Xojo load them faster.
# be sure to chmod +x unplug.sh
# called like:
# ./unplug.sh [path to xojo]/plugins/*
# e.g.
# /Users/cs/Desktop/unplug.sh /Applications/Xojo/Plugins/*
while [ -n "$1" ]
do
FILENAME=$1
if [[ ! -d "${FILENAME}" ]]
then
echo "Processing ${FILENAME}"
mv "${FILENAME}" "${FILENAME}.zip"
mkdir "${FILENAME}"
yes | unzip -d "${FILENAME}" "${FILENAME}.zip"
rm "${FILENAME}.zip" #comment this line to not delete original files
fi
shift
done
# Thanks to Jim Mckay for creating the original. script.I’m a bit confused by this discussion, probably because I haven’t followed prior discussions on the subject.
Each time I update my MBS plugins sets, I download a dmg file and copy all the xojo_plugin files from the Plugins folder of the disk image to my Xojo/Plugins folder.
How are you, guys, getting zip files that you need to uncompress? I guess you don’t compress them to distribute onto several computers (or for fun)
Also, I don’t understand what are these subdirectories made for. I only have a Plugins folder in Xojo; would I need to split all the xojo_plugin files into subfolders to make Xojo start faster?
(yes, I’d like to start Xojo faster, of course).
Hi Arnaud,
A Xojo plugin is a zipped collection of folders with the filename extension changed from .zip to .xojo_plugin. By extracting the zip file to the native folder structure in your Plugins folder, you eliminate Xojo from the need to do the extraction each time that you load the IDE (this is what takes so long during the IDE launch if you have a lot of plugins).
Hi Tim,
Thank you very much for your answer.
So, if I get it right, the steps (from my configuration to obtain a faster start time) would be:
Change back the .xojo_plugin extension to zip
Extract these zip files normally. This would result in folders having the native structure, ready to be moved (having the correct, self-distinguishable names)
Move each folder to the Xojo’s Plugins folder (keeping the top folder in the move, because each folder under Plugins needs to be a single folder containing all the structure)
Restart the IDE.
Am I correct?
P.S.: I could also use the shell script provided in this thread, but it’ll be faster for me to do it manually (I would certainly be able to remember how to execute such scripts; only it would take some minutes to try and fight with errors since I rarely do that. I’m not a Unix guy).
I think so, but ensure the top unzipped parent folder is renamed to include the .xojo_plugin part on the end. So the top parent folder is named exactly the same as the original plugin, but instead of the plugin icon, you now have a folder icon.
Maybe you’re already doing this, but it wasn’t clear to me with what you wrote.
I hope that helps.
The speed difference between .xojo_plugin as zip or folder is very small here.
If you save 10% on startup, you can be happy.
The bigger thing would be to rearrange the packages to get faster pre-compilation.
[quote=475432:@Christian Schmitz]If you save 10% on startup, you can be happy.
[/quote]
I save more like 65% on Linux and macOS here with the full MBS, Einhugur, and my personal plugins. From over 2 minutes to less than 25 seconds.
You are correct in your steps outline, but I would urge you to use the script as it is in my last version post above.
I’ve been working on a plugins manager very slowly for more than a year. Recently it’s really started to take shape. I have been working with plugin authors like Björn and Christian to do some really cool things. Of course, it will unzip the plugins into place 
It’s still in alpha stages, so it’s not quite ready to share. A public beta will be available soon, but if you’re on the verge of writing your own scripts and really need something better feel free to shoot me a private message.
What I would like to see is for the IDE to smiply perform the unpack on the first run that includes any new zipped plugins. Disk space is not longer the problem that it was back in REALbasic days.
It would have to unpack to a user writeable place (ie/ application support) as not all users will be able to unpack them right next to the IDE in the plugins dir
Hmm I knew about that but, actually, I wouldn’t have thought of that right now. Thanks for the reminder.
I’ll use it, later (once I set it up on my main computer).
Currently, I’m trying to set this up on a MacBook Pro. It didn’t work in my earlier tests. No plugin got loaded.
I finally found the problem. All .xojo_plugin folders must be enclosed inside a main folder. That’s rather counter-intuitive, as .xojo_plugin files are directly located in the Plugins folder, while .xojo_plugin folders must be contained as subfolders.
Anyway, I tried with the working setup: with zip formatted files, Xojo took 9 minutes to load. With .xojo_plugin folders, only 8 minutes were necessary.
I’m now wondering what I’ll do with that free minute
Right, it may concern some users (my guess is most plugins users would be the ones having installed the IDE). Xojo could fairly well define an alternate Plugins folder for each user.