3 ms·
Code size is in almost no way an indicator of performance or bloat. Ik can write a program that will use 100% CPU in about 10 LOC, while there can be very well
by dtech 13y ago
Code size is in almost no way an indicator of performance or bloat.
Ik can write a program that will use 100% CPU in about 10 LOC, while there can be very well-optimized pieces of software can be thousands to millions LOC.
e.g. the Quake 3 engine is probably as well optimized as you can make it and is about 300K LOC: https://github.com/id-Software/Quake-III-Arena https://github.com/id-Software/Quake-III-Arena
- clarry 13y agoIn my book bloat and performance are two entirely different things, and I think there is a strong correlation between code size and bloat. I agree about highly optimized code being typically larger than the simpler alternative. Now nginx has interesting optimizations in some places (e.g. the http parser), but if you read the code, it's not like 90% of the code in nginx is there due to optimization. I'd like to add that from an OpenBSD perspective, excess optimizations would no doubt be considered bloat as well. One of the goals is that the code is clean, correct, and secure. I know for a fact that the developers are not going to carefully audit and maintain millions of lines of micro-optimizations. What these might get you is a tick in a hypothetical feature checklist ("performance"). But if another daemon does the job and performs well enough, then that feature is unneeded complexity, hence bloat. Not something you want to include in what aims to be the world's most secure general purpose operating system.