Significant GC performance penalty

[H. S. Teoh]

On Fri, Dec 14, 2012 at 09:08:16PM +0100, Peter Alexander wrote:
> On Friday, 14 December 2012 at 19:24:39 UTC, Rob T wrote:
[...]
> >It may be that the GC concept works far better in theory than in
> >practice, although due to the performance penalty work-a-rounds,
> >you may end up writing better performing apps because of it,
> >however that's NOT the intention of having a GC!
> 
> When it comes to performance, there is always a compromise with
> usability. Even malloc performs poorly compared to more manual
> memory management. Even automatic register allocation by the
> compiler can lead to poor performance.
> 
> The only question is where you want to draw the line between
> usability and performance.

Yeah. If you want to squeeze out every last drop of juice your CPU's got
to offer you, you could code directly in assembler, and no optimizing
compiler, GC or no GC, will be able to beat that.

But people stopped writing entire apps in assembler a long time ago. :-)

(I actually did that once, many years ago, for a real app that actually
made a sale or two. It was a good learning experience, and helped me
improve my coding skills just from knowing how the machine actually
works under the hood, as well as learning why it's so important to write
code in a well-structured way -- you have no choice when doing
large-scale coding in assembler, 'cos otherwise your assembly code
quickly devolves into a spaghetti paste soup that no human can possibly
comprehend. So I'd say it was a profitable, even rewarding experience.
But I wouldn't do it again today, given the choice.)


T

-- 
Ruby is essentially Perl minus Wall.