3 ms·
not just for them. This also helps a lot for all OS packagers because right now they have to ship multiple custom nginx packages. As a user you either don't get
by pilif 11y ago
not just for them. This also helps a lot for all OS packagers because right now they have to ship multiple custom nginx packages. As a user you either don't get what you want or you get way too much.
Plus, if there's a custom module you'd really like to have in your nginx you're practically forced into building your own because there's no way to get that module loaded into the distro nginx.
Yes. There's some overhead to dynamic modules. Yes. There's a (minuscule) performance advantage to static linking.
But having the ability to ship modules independently of the web server core is a very important usability feature which, frankly, outweighs the performance overhead for most installs.
If you're really CPU bound on that nginx instance where you need the additional modules and you removing that overhead gives you that little bit extra performance you need, then you always have the option of hard-linking them.
- geocar 11y ago> There's a (minuscule) performance advantage to static linking. Is that actually true? I would have thought networking latency overshadows any memory latency introduced in a `call foo@PLT` v. `call *(foo@GOT)`. Are you aware of anyone who has benchmarked this? i.e. not a microbenchmark e.g. inside something like nginx? If so, it might be worth fixing the dynamic linker: the cost difference is absolutely fixable, as it's a tradeoff for sharing pages with other processes.
- snuxoll 11y ago> This also helps a lot for all OS packagers because right now they have to ship multiple custom nginx packages. As a user you either don't get what you want or you get way too much. I guess it allows us to split the nginx-included modules into separate packages, but it does nothing to aid with packaging extra modules until nginx provides a stable ABI for modules to use.