OSNews thread here degenerates into GC vs not

[Lutger]

Bill Baxter wrote:
  > With a tight schedule, a good strategy is to not waste time optimizing
> any one particular thing until you *know* it is a bottleneck.  Game 
> developers tend to be pretty ruthless in applying this principle.  For 
> the Civ4 SDK, something that will only be used directly by a tiny 
> fraction of Civ4 users, there's just not a lot of bottom line 
> justification for putting resources there, when compared to say fixing a 
> crash bug that 10% of players are likely to encounter.
> 
> So yeh, that's why folks like the Civ team and the folks behind Eve 
> Online are willing to go with Python.  For most things Python is fast 
> enough, and gets the job done much more quickly than C++.  For the small 
> fracton of the code where it's not fast enough, you can always re-write 
> those bits in C and call it from Python.
> 
> --bb

Civilization 4 is structured in roughly 4 layers:
1. core engine build on gamebryo (C++) - closed source
2. core game logic (120K LoC, a C++ DLL) - open source
3. python scripting (game logic, ui, terrain generation, etc.)
4. xml data (static data)

The C++ SDK is layer 2, so this affects all users. I don't know where 
bottlenecks lie here, but I suspect it is in 1 or 2.

I'm not sure (nobody is as it hasn't happened yet), but I wouldn't be 
surprised that if these parts of a large game are written in D 
performance will go up instead of down, even if the D compiler doesn't 
optimize as well as a good C++ compiler. For this kind of application I 
can't believe a little slower floating point calculation will matter as 
much as ease of high level design and maintenance optimizations.