4 ms·
perhaps slightly naive question, but whats the actual performance implication 10% increase in code size? (10% slower at runtime?)
by andrekandre 4y ago
perhaps slightly naive question, but whats the actual performance implication 10% increase in code size? (10% slower at runtime?)
- MobiusHorizons 4y agoIn the embedded world, you are limited by the amount of storage space available for your code. In a lot of cases the code is in flash or one time programmable rom memory on the microcontroller. Even if you have off-chip storage, you usually have to load the code into ram in order to run, and ram size is also quite limited. For low end microcontrollers it's common for rom / ram sizes to be on the order of 32kb (although they go much lower than that). In this world, the most common optimization level is -Os (or -Oz if available) because running out of storage space means you need a more expensive microcontroller, which increases the cost of each device you are selling, and might require a redesign of the PCB.
- FullyFunctional 4y agoThere isn’t a simple relationship. Ignoring the code space issue (and I$ pressure), the added instructions in this case are for function entry/exit so if that not on your hot path, it might not matter at all.
- xobs 4y agoAs others have noted, the issue isn't execution speed. Rather it's the fact that the memory and disk requirements increase by 10% which has a measurable effect on cost. We currently load the entire program into RAM to make things easier, so anything to lower storage requirements is a win. Someday we'll be able to mmap the disk to do XIP, but we don't have that implemented yet.
- andrekandre 4y agoi see, so mostly cost/resource issue, appreciate the answer!