3 ms·
this is all very interesting, especially to see the end result, but as a rule i don't leak memory or use garbage collection. again i am left feeling that garba
by jheriko 13y ago
this is all very interesting, especially to see the end result, but as a rule i don't leak memory or use garbage collection.
again i am left feeling that garbage collection causes more problems than it solves. certainly every instance of debugging a memory 'leak' in that context is much harder than it needs to be (don't use gc or refcounting) - and also a slap in the face considering this is the problem its meant to solve anyway.
if you care this much about performance your biggest bottleneck is the gc - not just interms of performance cost, but the amount of your time you will waste solving a problem like this instead of optimising your code.
this is a problem i don't need to solve and pretty much everything i write is high performance code... whilst i know this isn't targetted optimisation, but a fun experiment, i would worry that people will read some kind of best practice here where it really isn't...
- icebraining 13y agoIt's not the gc that causes this problem. The problem is: you allocated a block of, say, 100KB. Then you needed two 10KB subsets of that block. While you're using those, you may stop needing the rest of the block. How do you create those subsets? Do you just point to the original memory? Then you can't free() the 80KB you don't need anymore. Do you copy those 20KB? Then you're potentially using more memory than necessary. The problem holds even if you're not using a gc or refcounting at all.