"Brad Beveridge" <brad@somewhere.net> wrote in message news:d9ek1q$2in8$1@digitaldaemon.com...
> Sean Kelly wrote:
>
>>
>> Not only Phobos but the *core language*.  Remember, dynamic arrays (and
>> associative arrays) are built on the GC.  To avoid GC you'd have to
>> pretend D
>> were C and use pointers for all your storage needs.
>>
>>
> Which, if I were to try and use D without a GC is exactly how I would do
> it.  If you want to avoid the GC in D I am assuming that you want to avoid
> it for performance reasons (lets not talk about avoiding the GC for pure
> masochistic reasons :)).  In which case you must have profiled your code,
> found that there is a certain area that is slow/non-deterministic
> _because_ of the garbage collector and now you are trying to fix it.
> Fixing it could involve
> 1) Preallocate before the critical areas
> 2) Use freelists in the critical areas
> 3) Use memory that is outside the garbage collected areas and don't use
> new or dynamic arrays inside the critical areas
> 4) Don't allocate at all inside the critical areas

You've forgot to mention: delete.
If you know that allocated block is not used anymore - delete it.
D is using ordinary heap. And GC is running on this heap.
As less 'garbage' you have allocated as less GC cycle would be.
Using 'delete' at least is not slower than in C++.

Ref-counting is a method of deterministic GC. Combined
with current D non-deterministic GC can create unbeatable pair.

Ref-counting is a *choice* of developer to create better and optimal system.  D just does not provide such choice.

>
> If the garbage collector is slowing your whole program & you can't use any of the above, then I suggest that you have chosen the wrong language for what you're trying to do.
>
> I guess to sum up, my opinion is: D has a GC, thinking that the GC will cause performance problems before you have written any code is just premature optimisation.
>

But to think first is always a good thing right?

Coputational complexity of auto_ptr (new/delete) is
O(1) and letting GC do all your deletion is O(2*n).

Please don't forget that this topic is not about only GC and heap
allocations.
It is also about stack allocations and *this* is more than 100 times faster
than any
heap and GC.

Real example: in Harmonia I have class named Graphics. It is clearly
temporary wrapper
around HDC (on windows)

class Graphics { HDC hdc; }

I am *forced* to allocate it on heap:

void paint()
{
   auto  Graphics gx = new Graphics(window());
   draw(gx);
}

Paint is one of the most frequent events in GUI.
D is not letting me to implement it with maximum efficiency.

Andrew Fedoniouk wrote:

> Real example: in Harmonia I have class named Graphics. It is clearly temporary wrapper
> around HDC (on windows)
> 
> class Graphics { HDC hdc; }
> 
> I am *forced* to allocate it on heap:
> 
> void paint()
> {
>    auto  Graphics gx = new Graphics(window());
>    draw(gx);
> }
> 
> Paint is one of the most frequent events in GUI.
> D is not letting me to implement it with maximum efficiency.
I was going to ask why Graphics isn't a singleton - but really the example doesn't matter, it doesn't change the fact you can't easily allocate classes on the stack.
I guess our best bet is to gripe about things in the NG and post feature requests here http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList

Brad

In article <d9ek1q$2in8$1@digitaldaemon.com>, Brad Beveridge says...

>If the garbage collector is slowing your whole program & you can't use any of the above, then I suggest that you have chosen the wrong language for what you're trying to do.

Yup. This is all I was saying in my original post. There exists a sizeable subset of C++ programmers for whom D is not a viable alternative, whether they want to switch or not.

>I guess to sum up, my opinion is: D has a GC, thinking that the GC will cause performance problems before you have written any code is just premature optimisation.

A peculiar statement, particularly since D trumpets speed as a selling point. The basic characteristics and tradeoffs of GC have been well-known for decades. You don't need to write and profile a project in a new GC language to have concerns about GC performance in general.

cheers
Mike

Not exactly.  The library *is* what handles dynamic arrays.  You simply change that if you don't want it garbage collected.

Of course, you'll still have to handle the memory, but it's not like arrays are a black box you can't change.

-[Unknown]


> Not only Phobos but the *core language*.  Remember, dynamic arrays (and
> associative arrays) are built on the GC.  To avoid GC you'd have to pretend D
> were C and use pointers for all your storage needs.

You can allocate classes on the stack, as the documentation describes, it's just not recommended afaik.

http://www.digitalmars.com/d/memory.html#stackclass

Anyway, if this is all it really is:

class Graphics { HDC hdc; }

You could also, theoretically, use a struct - which is on the stack by default iirc.  Maybe that's "wrong" because it's not using OOP, but that's your choice not a restriction of D.

-[Unknown]


> "Brad Beveridge" <brad@somewhere.net> wrote in message news:d9ek1q$2in8$1@digitaldaemon.com...
> 
>>Sean Kelly wrote:
>>
>>
>>>Not only Phobos but the *core language*.  Remember, dynamic arrays (and
>>>associative arrays) are built on the GC.  To avoid GC you'd have to pretend D
>>>were C and use pointers for all your storage needs.
>>>
>>>
>>
>>Which, if I were to try and use D without a GC is exactly how I would do it.  If you want to avoid the GC in D I am assuming that you want to avoid it for performance reasons (lets not talk about avoiding the GC for pure masochistic reasons :)).  In which case you must have profiled your code, found that there is a certain area that is slow/non-deterministic _because_ of the garbage collector and now you are trying to fix it. Fixing it could involve
>>1) Preallocate before the critical areas
>>2) Use freelists in the critical areas
>>3) Use memory that is outside the garbage collected areas and don't use new or dynamic arrays inside the critical areas
>>4) Don't allocate at all inside the critical areas
> 
> 
> You've forgot to mention: delete.
> If you know that allocated block is not used anymore - delete it.
> D is using ordinary heap. And GC is running on this heap.
> As less 'garbage' you have allocated as less GC cycle would be.
> Using 'delete' at least is not slower than in C++.
> 
> Ref-counting is a method of deterministic GC. Combined
> with current D non-deterministic GC can create unbeatable pair.
> 
> Ref-counting is a *choice* of developer to create better and optimal
> system.  D just does not provide such choice.
> 
> 
>>If the garbage collector is slowing your whole program & you can't use any of the above, then I suggest that you have chosen the wrong language for what you're trying to do.
>>
>>I guess to sum up, my opinion is: D has a GC, thinking that the GC will cause performance problems before you have written any code is just premature optimisation.
>>
> 
> 
> But to think first is always a good thing right?
> 
> Coputational complexity of auto_ptr (new/delete) is
> O(1) and letting GC do all your deletion is O(2*n).
> 
> Please don't forget that this topic is not about only GC and heap allocations.
> It is also about stack allocations and *this* is more than 100 times faster than any
> heap and GC.
> 
> Real example: in Harmonia I have class named Graphics. It is clearly temporary wrapper
> around HDC (on windows)
> 
> class Graphics { HDC hdc; }
> 
> I am *forced* to allocate it on heap:
> 
> void paint()
> {
>    auto  Graphics gx = new Graphics(window());
>    draw(gx);
> }
> 
> Paint is one of the most frequent events in GUI.
> D is not letting me to implement it with maximum efficiency.
> 
> 
> 
> 
> 
> 
> 
> 
> 

"Brad Beveridge" <brad@somewhere.net> wrote in message news:d9eo51$2nkn$1@digitaldaemon.com...
> Andrew Fedoniouk wrote:
>
>> Real example: in Harmonia I have class named Graphics. It is clearly
>> temporary wrapper
>> around HDC (on windows)
>>
>> class Graphics { HDC hdc; }
>>
>> I am *forced* to allocate it on heap:
>>
>> void paint()
>> {
>>    auto  Graphics gx = new Graphics(window());
>>    draw(gx);
>> }
>>
>> Paint is one of the most frequent events in GUI.
>> D is not letting me to implement it with maximum efficiency.
> I was going to ask why Graphics isn't a singleton - but really the

"why Graphics isn't a singleton".
It is RAII thing. Needs to bee freed as soon as posible and order
of creation deletion matters. And each window, image, etc. has its own type
of Graphics.
Speaking about RAII: there are many things which I am doing
in C++  using auto objects (pen, brush, font - OS handles)
In D I was forced to do deallocation explicitly - and this does not simplify
my life. Thrown errors may create resource leaks so I was forced
to redesign hevily what I have in C++ to avoid this.

> example doesn't matter, it doesn't change the fact you can't easily
> allocate classes on the stack.
> I guess our best bet is to gripe about things in the NG and post feature
> requests here http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList

Most of features added recently are not in this list. So what is the point maintaining it?

------------
This is from D documentation:
"To have a class allocated on the stack that has a destructor, this is the
same as a declaration with the auto attribute. Although the current
implementation does not put such objects on the stack, future ones can."
Read last statement. It is already planned as far as I can see.

I think it is more convenient to implement ctors/dtors in structs though as
this will cover other
use cases also.

Andrew.

"Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:d9esl7$2sdf$3@digitaldaemon.com...
> You can allocate classes on the stack, as the documentation describes, it's just not recommended afaik.
>
> http://www.digitalmars.com/d/memory.html#stackclass
>
> Anyway, if this is all it really is:
>
> class Graphics { HDC hdc; }
>
> You could also, theoretically, use a struct - which is on the stack by default iirc.  Maybe that's "wrong" because it's not using OOP, but that's your choice not a restriction of D.

http://www.digitalmars.com/d/memory.html#stackclass

Sorry, but it does not call destructors.
Good common library design *must* assume that
exception can be thrown in user supplied drawing
implementations.

class Graphics {
    HDC hdc;
    this() { hdc = GetDC(....); .... }
    ~this() { ...; ReleaseDC(hdc); }
}

And library as good OS citizen *must* free OS resources allocated.

This is all about RAII.

>
> -[Unknown]
>
>
>> "Brad Beveridge" <brad@somewhere.net> wrote in message news:d9ek1q$2in8$1@digitaldaemon.com...
>>
>>>Sean Kelly wrote:
>>>
>>>
>>>>Not only Phobos but the *core language*.  Remember, dynamic arrays (and
>>>>associative arrays) are built on the GC.  To avoid GC you'd have to
>>>>pretend D
>>>>were C and use pointers for all your storage needs.
>>>>
>>>>
>>>
>>>Which, if I were to try and use D without a GC is exactly how I would do
>>>it.  If you want to avoid the GC in D I am assuming that you want to
>>>avoid it for performance reasons (lets not talk about avoiding the GC for
>>>pure masochistic reasons :)).  In which case you must have profiled your
>>>code, found that there is a certain area that is slow/non-deterministic
>>>_because_ of the garbage collector and now you are trying to fix it.
>>>Fixing it could involve
>>>1) Preallocate before the critical areas
>>>2) Use freelists in the critical areas
>>>3) Use memory that is outside the garbage collected areas and don't use
>>>new or dynamic arrays inside the critical areas
>>>4) Don't allocate at all inside the critical areas
>>
>>
>> You've forgot to mention: delete.
>> If you know that allocated block is not used anymore - delete it.
>> D is using ordinary heap. And GC is running on this heap.
>> As less 'garbage' you have allocated as less GC cycle would be.
>> Using 'delete' at least is not slower than in C++.
>>
>> Ref-counting is a method of deterministic GC. Combined
>> with current D non-deterministic GC can create unbeatable pair.
>>
>> Ref-counting is a *choice* of developer to create better and optimal system.  D just does not provide such choice.
>>
>>
>>>If the garbage collector is slowing your whole program & you can't use any of the above, then I suggest that you have chosen the wrong language for what you're trying to do.
>>>
>>>I guess to sum up, my opinion is: D has a GC, thinking that the GC will cause performance problems before you have written any code is just premature optimisation.
>>>
>>
>>
>> But to think first is always a good thing right?
>>
>> Coputational complexity of auto_ptr (new/delete) is
>> O(1) and letting GC do all your deletion is O(2*n).
>>
>> Please don't forget that this topic is not about only GC and heap
>> allocations.
>> It is also about stack allocations and *this* is more than 100 times
>> faster than any
>> heap and GC.
>>
>> Real example: in Harmonia I have class named Graphics. It is clearly
>> temporary wrapper
>> around HDC (on windows)
>>
>> class Graphics { HDC hdc; }
>>
>> I am *forced* to allocate it on heap:
>>
>> void paint()
>> {
>>    auto  Graphics gx = new Graphics(window());
>>    draw(gx);
>> }
>>
>> Paint is one of the most frequent events in GUI.
>> D is not letting me to implement it with maximum efficiency.
>>
>>
>>
>>
>>
>>
>>
>> 

Andrew Fedoniouk wrote:
> 
> http://www.digitalmars.com/d/memory.html#stackclass
> 
> Sorry, but it does not call destructors.
> Good common library design *must* assume that
> exception can be thrown in user supplied drawing
> implementations.
I think that the only solution to this is to wait :)
Walter can obviously see that auto classes should be put on the stack, I guess he just hasnt gotten to the optimisation phase of DMD's development yet.  I would expect optimisation to begin post v1.0 myself.

Brad

"Mike Capp" <mike.capp@gmail.com> wrote in message news:d9eri2$2rg0$1@digitaldaemon.com...
> In article <d9ek1q$2in8$1@digitaldaemon.com>, Brad Beveridge says...
>
>>If the garbage collector is slowing your whole program & you can't use any of the above, then I suggest that you have chosen the wrong language for what you're trying to do.
>
> Yup. This is all I was saying in my original post. There exists a sizeable
> subset of C++ programmers for whom D is not a viable alternative, whether
> they
> want to switch or not.
>
>>I guess to sum up, my opinion is: D has a GC, thinking that the GC will cause performance problems before you have written any code is just premature optimisation.
>
> A peculiar statement, particularly since D trumpets speed as a selling
> point.
> The basic characteristics and tradeoffs of GC have been well-known for
> decades.
> You don't need to write and profile a project in a new GC language to have
> concerns about GC performance in general.

Agreed. I though that GC euphoria already gone but....
GC is just one more way of managing memory. With pluses and minuses.

Good new language shall provide developers at least choice what to use:
in some places stack type of memory management is better, in other heap
and of course GC. The best results can be achieved in combination of these.

http://www.geocities.com/carsten_frigaard/the_toll_of_garbage_collection.pdf

Andrew.

In article <d9esdf$2sdf$2@digitaldaemon.com>, Unknown W. Brackets says...
>
>Not exactly.  The library *is* what handles dynamic arrays.  You simply change that if you don't want it garbage collected.
>
>Of course, you'll still have to handle the memory, but it's not like arrays are a black box you can't change.

But how do you do this without garbage collection?  Almost any operation on a dynamic array might require a memory allocation, and the old memory has to go somewhere.  If it's cleaned immediately then you could be stuck with dangling pointers (please note that I'm trying to look at this from a compiler/library writer's perspective).  I suppose it may be possible to implement a conforming D compiler that does reference counting instead of garbage collection, but I'm not sure it would be a worthwhile endeavor.


Sean