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.