3 ms·
Well, if you wanna go that route, in the general case, code will be structured differently. On one side, you have duck typing, closures, automated memory manage
by woofie11 6y ago
Well, if you wanna go that route, in the general case, code will be structured differently. On one side, you have duck typing, closures, automated memory management, and the ability to dynamically modify code.
On the other side, you don't.
That linguistic flexibility often leads to big-O level improvements in performance which aren't well-captured in microscopic benchmarks.
If the question is whether GC will beat malloc/free when translating C code into a JIT language, then yes, it will. If the question is whether malloc/free will beat code written assuming memory will get garbage collect, it becomes more complex.
- mpweiher 6y agoObjective-C has duck typing (if you want), closures, automated memory management and the ability to dynamically modify code. And is AOT compiled. GC can only "beat" malloc/free if it has several times the memory available, and usually also only if the malloc/free code is hopelessly naive. And you've got the micro-benchmark / real-world thing backward: it is JITs that sometimes do really well on microbenchmarks but invariably perform markedly worse in the real world. I talk about this at length in my article (see above).