logoalt Hacker News

tomjen3 • today at 9:00 AM • 1 reply • view on HN

All types of architecture have advantages and disadvantages. Clean code might not be very cache-friendly, but it does a pretty good job of making sure you don't have to hunt in too many places to update things and It also makes it pretty simple to split things up so that you can write unit test for most everything.

This is not the right choice for everything, just as using Python is not the right choice for everything. The question to ask is: what are we trying to do in the first place? Then take it from there.

You did that by making sure the speed-up was business relevant. I'm mostly putting this out to force people to think about whether that also applies to their specific thing.


Replies

boricj • today at 9:27 AM

"Clean" code for modelling links between objects would be to store pointers within them. But that means dangling pointers when deleting objects, so you need to either update manually everywhere (easy to forget somewhere) or use shared/weak pointers (extra bookkeeping and allocations).

"Unclean" code for this is putting objects in a table, giving objects a generation (that increments whenever you create/delete one) and storing pairs of (index, generation) numbers everywhere you need a link. Link is live only if the generations matches and since only odd generations are live objects, default construction means no link. Lifted straight from 2000s video game tricks and with modern C++ it's basically all encapsulated away.

I've made that refactoring in a codebase, not because of speed but because of maintenance and memory fragmentation concerns. Sometimes, the clean solution really isn't the right one and it's really sad that compsci only ever teaches classical data structures, like we're still coding in the 1970s on computers with no caches that don't suffer from pointer chasing.