--- Comment #120 from Vladimir <> 2011-04-14 19:50:08 
PDT ---
(In reply to comment #118)
> > I hope it is as you say it is, but without benchmarks it's hard to say
> > anything, and this talk of state machines etc. is disconcerting.
> Why?

It "sounds" slower. This is subjective and unscientific. That's why I said only
a benchmark will show the real results.

> Also, even if the compiler emits the tables necessary for more precise gc, the
> gc implementation can ignore them and do it the old way. Emitting the tables
> makes it possible for people to experiment with various kinds of gc 
> strategies.

I would like to avoid bloating executables any further, and giving reverse
engineers more data about my code. (I know executable size doesn't affect
performance, at least in theory, but it does matter and can't be completely
neglected either.)

> True, and it works tolerably well. To do a moving gc, however, you need more
> precise information.

I don't want a moving GC. I want a fast GC.

("I" in this context means D users with the same requirements, mainly video
game developers.)

I understand the advantages of a moving GC - heap compaction allowing for an
overall smaller managed heap etc., but I hope you understand that sacrificing
speed for these goals is not an unilateral improvement for everyone.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to