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.
