virtual-by-default rant

[Ary Manzana]

On 3/24/12 3:03 AM, Manu wrote:
> On 23 March 2012 17:24, Ary Manzana <ary at esperanto.org.ar
> <mailto:ary at esperanto.org.ar>> wrote:
>
>     On 3/18/12 9:23 AM, Manu wrote:
>
>         The virtual model broken. I've complained about it lots, and people
>         always say "stfu, use 'final:' at the top of your class".
>
>         That sounds tolerable in theory, except there's no 'virtual'
>         keyword to
>         keep the virtual-ness of those 1-2 virtual functions I have...
>         so it's
>         no good (unless I rearrange my class, breaking the logical
>         grouping of
>         stuff in it).
>         So I try that, and when I do, it complains: "Error: variable
>         demu.memmap.MemMap.machine final cannot be applied to variable",
>         allegedly a D1 remnant.
>         So what do I do? Another workaround? Tag everything as final
>         individually?
>
>         My minimum recommendation: D needs an explicit 'virtual'
>         keyword, and to
>         fix that D1 bug, so putting final: at the top of your class
>         works, and
>         everything from there works as it should.
>
>
>     Is virtual-ness your performance bottleneck?
>
>
> Frequently. It's often the most expensive 'trivial' operation many
> processors can be asked to do. Senior programmers (who have much better
> things to waste their time on considering their pay bracket) frequently
> have to spend late nights mitigating this even in C++ where virtual
> isn't default. In D, I'm genuinely concerned by this prospect. Now I
> can't just grep for virtual and fight them off, which is time consuming
> alone, I will need to take every single method, one by one, prove it is
> never overloaded anywhere (hard to do), before I can even begin the
> normal process of de-virtualising it like you do in C++.
> The problem is elevated by the fact that many programmers are taught in
> university that virtual functions are okay. They come to the company,
> write code how they were taught in university, and then we're left to
> fix it up on build night when we can't hold our frame rate. virtual
> functions and scattered/redundant memory access are usually the first
> thing you go hunting for. Fixing virtuals is annoying when the system
> was designed to exploit them, it often requires some extensive
> refactoring, much harder to fix than a bad memory access pattern, which
> might be as simple as rearranging a struct.

Interesting.

I spend most of my work time programming in Ruby, where everything is 
virtual+ :-P

It's good to know that virtual-ness can be a bottleneck.