4 ms·
Frequently the second problem is exacerbated by cache misses. Every operation becomes (much!) slower, but nothing stands out. Not a popular opinion here, but e
by yoklov 12y ago
Frequently the second problem is exacerbated by cache misses. Every operation becomes (much!) slower, but nothing stands out.
Not a popular opinion here, but excessive modularity like that is practically the definition of bad, hard to follow code though IMO. Ignoring performance issues, everything happens somewhere else, and large changes now take several times longer, since the changes are not local to a function. The code is several times longer than it otherwise would be due to all the function declarations...
Its a nightmare. It tends to be the kind of code you feel productive while writing ("I'm cleaning up this 200 line function"), but is really just making the codebase worse (is there a general term for this kind of false productivity? It's a common problem I see).
- _pmf_ 12y ago> Its a nightmare. It tends to be the kind of code you feel productive while writing ("I'm cleaning up this 200 line function"), but is really just making the codebase worse (is there a general term for this kind of false productivity? It's a common problem I see). This issue is pervasive when Desktop/Web developers try to improve embedded software. I've achieved a thousandfold increase in performance by converting an embedded data logger from using printf to using a dedicated formatting function (most of the time was spent on parsing the format string and performing allocations).
- TheLoneWolfling 12y agoThe compiler doesn't do the parsing for printf at compile time for the common cases? That's semi-surprising.