Garbage Collector

[rikki cattermole via Digitalmars-d]

On 16/06/2016 6:53 AM, Konstantin wrote:
> On Wednesday, 15 June 2016 at 17:02:11 UTC, rikki cattermole wrote:
>
>> Higher level languages like Java have the benefit of using pools and
>> optimizing for this usage pattern, D does and will never have this.
> Why don't you want the same for D?

Because we don't need them.
Sprinkling of fairy dust is for stories, not reality.

>> Well if you really insist to have a String class don't be too
>> surprised for some reason it doesn't have the same performance to say
>> Java.
> Some areas, like compiling, or producing HTML/XML/JSON documents,
> manipulate strings a lot.
> Other areas, like GUI editors for sufficiently complex documents, or
> level editors for videogame, need to efficiently manipulate huge trees
> of assorted small objects, not necessarily strings.

You're quite right and that is why we have a GC to begin with.
Its also part of the reason why std.experimental.allocator will allow 
you to create an allocator that is able to handle such work load and 
then free when complete.

>> Aka don't go around creating/destroying classes a huge amount unless
>> you have rolled some form of memory management policy such as
>> reserving memory for the GC to use.
> Yeah, that’s what I regularly do in C++ when I need to efficiently
> create/destroys many small objects. Sure, this typically leads to the
> best performance, e.g. because I can make the memory layout as cache
> friendly as humanly possible.
> But not all projects need that. And even for very performance demanding
> apps, not all components of the app need that.
> For such cases, a good GC (that just works well out of the box like
> .NET's GC does) can reduce development costs significantly.

So exactly like what our GC does do. Unless you're doing real time 
development in any form (e.g. sound) you won't need to do much to work 
around the GC.