-nogc

[dennis luehring]

Andrei Alexandrescu schrieb:
> dennis luehring wrote:
>> Andrei Alexandrescu schrieb:
>>> 1. Put array definitions in object.d. Have the compiler rewrite "T[]" ->
>>> ".Array!(T)" and "[ a, b, c ]" -> ".Array!(typeof(a))(a, b, c)". I think
>>> superdan suggested that when he wasn't busy cursing :o).
>>>
>>> 2. Do the similar thing for associative arrays.
>>>
>>> 3. Have two object.d at hand: one is "normal" and uses garbage
>>> collection, the other (call it object_nogc.d) has an entirely different
>>> definition for arrays, hashes, and Object.
>> 
>> question about debug code speed:
>> 
>> a far as i understand it now is the code-speed of (assoc) arrays 
>> independent from the debug-code-generator because of the buildinness
>> 
>> i ask because i hate the speed of std::vectors/maps at debug-time
>> especially when it comes to large datasets - my major slowdown in 
>> prototype development comes then from the awfully slow stl containers - 
>> does D suffer from this - or will it, when you add this extension?
> 
> I think we'll be in better shape than debug stl because ranges are 
> inherently cheaper to check. But only testing will tell.

not only iterating is awfully slow - also the pushing of data

(i can clearly say that my simple stl container based volume simulation
is nearly not debugable because of the amount of data needed to get into 
an debugable state) - so im working only with release versions - and 
start to convert my (c++)modules into relaseable c-interfaced dlls
(just to be able to debug the main-code) - and this situation is an 
absolut prototyping no-go

please: always test if your extensions to containers do not harm the 
"debugging" speed - the stl is best example of killing this part of 
prototype-test-programm-cycle