How does that fit? What would be the evil of not wasting memory for many years at 1x?

jgrahamc 5 hours ago | parent | next [-]

One of the "evils" of premature optimization is how much time you spend on the optimization vs. the benefit you get from it. If your goal is correctness and shipping fast and you're not memory constrained then spending time using the least amount of memory is a waste of time specifically because you want to ship fast.

Another interesting thing that happens is you don't necessarily know what form your actual optimizations will need to take. Later when your systems grow you discover the suboptimal parts you hadn't optimized for.

Very early on at Cloudflare I worked on part of the DNS infrastructure that took DNS records from the UI and got them in a state for actual authoritative serving. The system had been constructed anticipating Cloudflare having millions of customers with unique domains, but it had not been constructed for a single customer with a single domain with millions of records. This caused a periodic slow down in DNS record updating while the system churned on that one customer.

In a different job I worked on a piece of optimization software that needed to keep track of "node" A is reachable from node "B". This had been implemented as a matrix (literally a malloced NxN matrix of ints storing 0 or 1) which worked really well for small systems. But you'd be out of memory really fast on a large project. I replaced the matrix with a hash table and all was good because the matrix was actually really sparse.

	▲	stickfigure 4 hours ago \| parent [-]
		Absolutely true, but I will say that LLMs have changed the equation somewhat. With a rather short prompt, claude/codex will take your code, write a harness, profile it, build experiments, profile those, and give some pretty solid advice which one to pick. Then integrate the changes. It's the kind of goal-directed, bite-sized job that LLMs excel at. Extremely low-commitment. Except for the whole "making changes in production at scale" problem, of course.

▲

gbear605 5 hours ago | parent | prev [-]

Engineers are expensive, especially good system engineers who are trained in your code base. Very possible that this just hadn't gotten to the top of the priority list.

▲

eviks 4 hours ago | parent [-]

I don't understand why you need training on your code base to design a cache format for read only vs rw workloads, but anyway yours is a comment about neglect, not the "evil" that would happen if you did that design

▲

Spooky23 4 hours ago | parent | next [-]

I see your point but disagree. Engineering is about constraints. Time, materials, labor, scope.

The “evil” of premature optimization is that it’s a misapplication of priority. If I have an acute medical problem that needs attention, it’s not the right time to talk about chloresterol and statins, get my broken leg set.

There’s always a tension between engineering management who needs to deliver a solution to the business and engineers who want to deliver a beautiful object.

▲

win311fwg 4 hours ago | parent | prev [-]

> I don't understand why you need training on your code base to design a cache format

Because anyone willing to come in just to design your cache format is going to expect payment that is many multiples more than the engineers you already cannot afford? Long-term employees cost less, which brings them closer to being affordable, but you have to be able to keep them busy for long periods of time to realize that reduction in cost. A engineer who doesn't understand your codebase isn't going to be useful for very long.

	▲	eviks 4 hours ago \| parent [-]
		You explained why it's beneficial for other workloads, but the original point was about this specific design