In general you want as few as possible of both.

You could also optimize everything for future updates that optimize things even further for even more updates...

Humm.. that was supposed to be a joke but our law making dev team isn't all that productive to put it mildly. Perhaps some of that bloat would be a good thing until we are brave enough to do the full rewrite.

▲

banana_sandwich 42 minutes ago | parent | prev | next [-]

[dead]

▲

AceJohnny2 an hour ago | parent | prev [-]

that's right. This is the reason all my code looks like an entry to PerlGolf. /s

The world's complicated. "Every complex problem has a solution which is simple, direct, and wrong"

Simplicity is a laudable goal, but it's not always the one thing to optimize for.

▲

lo_zamoyski an hour ago | parent [-]

Ah, but "simplicity" is not necessarily "fewest lines of code".

Code is first and foremost for human consumption. The compiler's job is to worry about appeasing the machine.

(Of course, that's the normative ideal. In practice, the limits of compilers sometimes requires us to appease the architectural peculiarities of the machine, but this should be seen as an unfortunate deviation and should be documented for human readers when it occurs.)

	▲	AceJohnny2 18 minutes ago \| parent [-]
		> Code is first and foremost for human consumption. The compiler's job is to worry about appeasing the machine. Tangentially, it continues to frustrate me that C code organization directly impacts performance. Want to factorize that code? Pay the cost of a new stack frame and potentially non-local jump (bye, ICache!). Want it to not do that? Add more keywords ('inline') and hope the compiler applies them. (I kind of understand the reason for this. Code Bloat is a thing, and if everything was inlined the resulting binary would be 100x bigger)