Hacker News Reader

Comment by MrBuddyCasino | Hacker News Reader

Why go through the trouble of

a) calculating maximum leakage

b) doubling physical memory

instead of just fixing the leaks? Was it to save cycles? Prevent memory fragmentation? I feel this story misses the details that would make it more than just a cute anecdote.

View on HN

"just fixing the leaks" can be a very time consuming process, involving hunting and refactoring (valgrind isn't perfect). It's very possible that just throwing more memory at it with the soft guarantee that the leak won't result in OOM may have been the best business decision for that particular contract. Of course it's not the "right" way to build a thing, but sometimes the job wants the thing now and "good enough."

It's possible it may have been running on bare metal without an OS. Maybe they didn't want to verify a memory allocator and just treated the whole program as one big arena. I presume by "calculating" they meant "run the program in worst case conditions and see how much memory it uses".

It was probably more efficient. Fixing leaks often requires copying instead of passing pointers.

I feel the same way too, dunno why the down votes? In the absence of all other details it just seems like shoddy work, but of course reality is probably more nuanced ... which is what's missing from the story.

I think the story isn't nuanced. The program runs once, the missile explodes, garbage collection is done!

No need for garbage collection, no need for "memory management". Not shoddy work. An expression of "YAGNI". The interesting thing (in my opinion), is the realization. The teller of the story went to the trouble of discovering that memory is leaking. She could have simply asked before engaging the work.

FredW

There is the cpu overhead of detecting where the memory goes out of scope and freeing it. So it can be a memory vs cup optimisation

It's a missile.

The memory is going to fragment no matter what you do.

Reply on news.ycombinator.com