Hi, sorry for the broad and vague question. I have read in some reddit post about benchmarks, that some code didn't use the final keyword on methods in a sense that final would make it faster, I believe.

I thought, without any D knowledge, it could be that with shorter code I might create virtual calls by accident. It might in some rare case have an impact on performance, but it might - on the good side - be the optimizer of one of the three compilers that puts that handling of maybe-virtual calls away or whatever might happen.

So, having no clue about D (just bought some books), I wanted to ask if nice looking code can become slow, in general. In the mentioned case it's just that I like the packaging of functions into some sort of scope (OOP) versus the flat C and Go stuff. I like OOP for this reason, but now I'm unsure whether I might stay out of creating classes at all.

I do like to write 'in' and 'ref' keywords at their places, for maybe creating some little speed benefits and safety, but the 'final' keyword I then might write because I opted in into OOP looks, for just the visual reason.

Uh, hope you understand my vague question, sorry about that. I found D to be the right place because it's not missing any essential feature I know of.

Kind regards

On Wednesday, 8 March 2023 at 10:49:32 UTC, Markus wrote:

Don't bother with it. This kind of optimization is done when compiling with -O, and I really doubt about your bottleneck being that you're calling a virtual call. Wait when you actually need to optimize before making your code ugly.

On Wednesday, 8 March 2023 at 10:49:32 UTC, Markus wrote:

If you write D like Java, it will be slow like Java - actually slower, because D's GC isn't as good.

If you remember to use structs for value types (no class Vector3f, class Point etc.), you should be fine.

Though as a general rule, don't worry about it too much. Even slow D is still fast.

On Wednesday, 8 March 2023 at 10:49:32 UTC, Markus wrote:

Well, bounds check often cost a few percent, and you can disable it or use .ptr
@safe will push you to use slices instead of raw pointers, and those can occupy the stack a bit more, but it's not a huge effect.
Lack of dangerous "fast math" "optimizations" is a real boon for correctness.
We don't have integers overflows, those would also cost a few percent.

Your D programs by being easy to modify will have very few performance bottlenecks that are problematic, often the CPU-bound or memory-bound stuff that would be slow in any language. For example I like to merge array allocations, this necessitates the same code in C, C++, or any native language.

I think it's important not to go overboard with lazy chains and templates though.

Honestly the increased productivity will leave you ample time to make things fast, and you can use the native profilers, for example Intel Vtune.

This year I released a free VST compressor named Lens, it does more than the closest manybands competitor while being in the ballpark CPU-wise, and they are using ICC AVX2 which does dynamic instruction set dispatch, while we use SSSE3. Optimization is all about having the time to do it.

On Wednesday, 8 March 2023 at 12:46:53 UTC, Hipreme wrote:

No they are not, simple example : https://godbolt.org/z/xfPqnWrrv
Obviously in a library test might be called with a derived so v1() target address must be read in the vtbl of the argument.

That is more true. vcalls dont add complexity.