Structs insted of classes for Performance

[Frustrated via Digitalmars-d-learn]

On Sunday, 20 April 2014 at 16:56:59 UTC, Ali Çehreli wrote:
> My understanding is not perfect. There may be compiler and CPU 
> optimizations that I am not aware of.
>
> On 04/20/2014 08:03 AM, Frustrated wrote:
>
> > is the only argument really about performance when creating
> > structs vs creating classes
>
> Not only creating but also when using. A class variable is a 
> reference to the actual object, implemented by the compiler as 
> a pointer. So, there is that extra indirection overhead to 
> access member variables of a class object.
>
> When the class variable and the object are far apart in memory, 
> they may be fall outside of CPU caches.
>
> Further, unless they are defined as final or static, class 
> member functions are virtual. Virtual member funtions are 
> dispatched through the virtual function table (vtbl) pointer. 
> So, a call like o.foo() must first hit the class vtbl in 
> memory, read the value of the function pointer off that table 
> and then jump to the function.
>
> Related to the above, class objects are larger than struct 
> objects because they have the extra vtbl pointer, as well as 
> another pointer (monitor) that allows every class object to be 
> used as a synchronization item in concurrency.
>
> Larger objects are more expensive because less of those can fit 
> in CPU caches.

Yes, but this is the standard argument between structs and 
classes. Obviously the additional benefits of classes cost... 
else no one would use structs. If structs had inheritance, there 
would be no real reason for classes.

I don't mind the cost of classes because I will try and use them 
were appropriately. Also, these problems are not language 
specific but simply because classes are heavier.

The article I read was about D's specific issues and that using 
structs GREATLY sped up certain things... I'm sure it had to do 
with the GC and all that but can't remember.

> > Basically that boils down to stack allocation vs heap
> allocation speed?
>
> Not to forget, struct objects can be allocated on the stack as 
> well by std.typecons.scoped.
>
> > Which, while allocation on the heap shouldn't be too much
> slower than
> > stack, the GC makes it worse?
>
> Stack allocation almost does not exist as some location on the 
> stack is reserved for a given object. There is no allocation or 
> deallocation cost at runtime other than certain decisions made 
> by the compiler at compile time.
>
> On the other hand, any dynamic allocation and deallocation 
> scheme must do some work to find room for the object at runtime.
>
> Ali


Again, all those arguments are about the specific difference 
between a struct and class and apply to all languages that use 
those types of structures.

In D though, I guess because of the GC(but which is why I am 
asking because I don't know specifically), classes could be much 
slower due to all the references causing the GC to take longer 
scan the heap and all that. If allocate or free a lot of classes 
in a short period of time it also can cause issues IIRC.

I just can't remember if there was some other weird reasons why 
D's classes are, in general, not as performant as they should be. 
If I remember correctly, I came across a page that compared a few 
test cases with the GC on and off and there was a huge factor 
involved showing that the GC had a huge impact on performance.