-
Notifications
You must be signed in to change notification settings - Fork 574
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build everything in mods/ and include it with the .app #3
Comments
Hydra did not have .so files for the included modules, instead it linked the .m bits right into the Hydra binary. This provides some virtual memory pressure (the executable pages become demand paged) which is uninteresting; it causes some static allocation/initialisation (on the order of kilobytes I bet); and in theory it could cause code to get run on startup instead of on require, but this is something we can control when accepting modules. If we are strict enough about the quality of modules we import, linking them all into our binary is an option. However, I don't see many benefits to this. I also see no downsides to shipping .so files with all modules that have .m files, keeping memory entirely free of unused modules. Opinions? |
Hi I say let's let the data decide, by measuring the difference between implicitly loading all the modules and not. Cheers, Chris Jones
|
👍 |
TLDR static linking all .m files will cause 0.5M of VM pressure and allocate a few hundred bytes. With all modules available as rocks installed:
i.e. loading every .so will cause around 600kbyte of virtual mapping, and 132 bytes of static allocation.
furthermore, there is around 130kbyte of Lua source in all of the rocks combined (82kb of which is from _asm ;). A very generous estimate would be that on load, due to compilation, this turns into one megabyte -- but note that the topic is not 'preload all .lua?' but 'prelink all .so'. |
However, static linking makes it harder for third party devs/hackers to override things from within their custom versions of modules, forcing them to put their author prefix not just in the package name but also the name of their meta table, in theory. I think this would go alright in practice, the way the modules currently look, but I feel .so will give more flexibility. |
For the out-of-box experience.
The text was updated successfully, but these errors were encountered: