-1 on more bloat It is a simple matter to see the cost of a PR if we add bloaty (https://github.com/google/bloaty) to ci.
-----Original Message----- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Thursday, July 30, 2020 12:25 PM To: dev@nuttx.apache.org Subject: Re: [GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1487: libc: Avoid ctype function to evaluate the argument more than once > But how long does it take you, when the linker tell you, you have over > flowed .text by 256 bytes? When you overflow memory due to a large number of modest size increases, there is no way to recover. You are basically screwed because nothing can really be done. The only way to prevent code bloat is by addressing each and every modest size increase as they are introduced. That is the only discipline that will keep the size of the OS within bounds. BTW: This started out as a discussion in PR #1487. I am not sure how it leaked into the dev list. But I think it is an important discussion that all people associated with the project should discuss. We are experiencing unbridled code growth now, especially since becoming an Apache project. Each release is 1Kb or so larger that the previous release on configurations that have no beneficial, functional improvements. This is pure code bloat. Certainly capabilities are increasing, but configurations that do not exploit those new capabilities are increasing in size with absolutely no benefit. Is this something we should be concerned about? Or should be let it go and just sweep every fractional Kb code increase under the rug where we hide all of the things that we are too lazy to address? This is a democracy. If you like it like that, that is cool.
