-nogc

[dennis luehring]

dennis luehring schrieb:
> 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

does that also mean that strings are getting template based?

what amount of debug-code will produce this? like with the stl (or 
boost) - zillion megabytes for 9 lines of code? and i can throw away my 
debugger (if D will get a good one)

im always shocked when looking at the stl/boost based assembler code in 
debug releases - does D generate less code?