On 16/06/2016 4:52 AM, Konstantin wrote:
On Wednesday, 15 June 2016 at 13:40:11 UTC, rikki cattermole wrote:
5. The requirements for our GC is quite intricate. I.e. you can't just
pop in one that doesn't understand about our Thread Local Storage (TLS)
and stuff.
D’s TLS that different from .NET's TLS?
https://msdn.microsoft.com/en-us/library/system.threadstaticattribute(v=vs.110).aspx
Yes it most definitely is.
We roll our own for platforms that do not support it.
There is an abstraction in druntime specifically to handle this problem.
I forgot to mention, good D code is not the same as a higher level
language like Java.
Here you don't have the automagick behavior of arrays. If you append
it will have a high cost. All allocations have a large cost. Instead
allocate in one large block which will of course be a whole lot faster
then small tiny ones.
You’re saying memory allocations in D are generally very expensive, but
that’s not a problem, because it already functions as designed?
No.
Memory allocations are /always/ expensive.
Higher level languages like Java have the benefit of using pools and
optimizing for this usage pattern, D does and will never have this.
Keep in mind an allocation = usage of malloc + write to returned pointer.
So even if the GC is enabled, good D code won't cause too much slow
down unless you decide to write heavy OOP code.
I’ve been developing heavy OOP code in various languages (mostly C++,
but also C# and Objective-C) for decades already. OOP works very well
for me.
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.
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.
We have other tools where OOP normally would be used such as templates,
structs, function pointers and delegates.
