Answering your questions is not easy. Because there is the current situation (i.e. Orchard 1.1) and what we could do in the future to improve. Let me answer with the "current situation" first.
As far as i figured out a precompiled extension (module) is an extension that contains the bin directory.
Correct: If a module has an assembly in "~/Modules/<MyModule>/bin", then that assembly will be loaded by the "precompiled extension loader"
Could it be (memory wise) better to have pre-compiled extensions? In that case i think i would "extend the extensionmanager" to save the dynamicly compiled assembly to the bin directory.
It could be. However, we are limited by Medium Trust. If you look at "dynamic extension loader", we use asp.net BuildManager (and have our custom build provider) to build .csproj files. This is the only way to generate code that is compatible with Medium
Trust. One of the limitiation is that we don't have access to the assembly file (it's stored somewhere in temp asp.net folder), we are given back the assembly already loaded in memory.
- Is a precompiled extension handled differendly? For example not being monitored etc?
It is handled differently in a sense that the module assembly is copied to "~/App_Data/Dependencies" before being loaded. The original assembly file is monitored too.
- Can or will a precompiled module with source be recompiled when the source is modified?
Currently, sources files are monitored even when a module is pre-compiled. This is so that, if a source file is modified and the module is not recompiled (e.g. WebMatrix or notepad editing scenario), the module will be re-compiled dynamically.
I took a quick dive into the ExtensionLoaders. As far as i figured out a precompiled extension (module) is an extension that contains the bin directory. Could it be (memory wise) better to have pre-compiled extensions? In that case i think i would "extend
the extensionmanager" to save the dynamicly compiled assembly to the bin directory.
- In the case of 100 modules would it be better to have 100 precompiled or 100 code-only (dynamic) modules?
Currently, if you are looking for the best possible performance, I think (even though I haven't measured) your best bet is to deploy all the module binaires to ASP.NET "~/bin", and remove all source code for modules and assemblies from "~/Modules/<MyModule>/bin". The
second best option would be to remove all source code and leave assemblies in "~/Modules/<MyModule>/bin". This would prevent Orchard from monitoring source code files and also trying to re-compile modules dynamically.
However, it is very *unlikely* that 100s of modules will scale well even if you deploy to "~/bin" (option above). In .NET, loading hundreds of small assemblies is slower than loading a few big ones. This is why, in the
future, we are considering having an "advanced" dynamic compilation loader/manager which would be able to compile all source code into one big assembly (or maybe a few big ones). To be able to do that though, Orchard would need to have the
source code of all modules available, which is different than the recommendation above. Finally, if you have an Orchard installation with 100s of modules, please share your exeperience with us (e.g. on this forum). We would like to understand the pain points.
Another option we are looking at (shorter term) is to offer "settings" to the Orchard compilation system so that a deployed site which is "stable" (i.e. modules are not edited or updated, but at the same idled out very often) can have better startup
performance. Stay tuned!