[ncmncm]

Space for vtables is almost always negligible, especially so on 64-bit targets. So the main effect of inflated vtables is cache footprint. But where that matters most, you probably shouldn't be doing virtual calls anyway.

Compilers don't get to say what you compile. People care about the speed of bad code almost as much as good code, and sometimes more: what bad code wastes, the compiler might be able to give some of back.

Code that has a preponderance of vtables is usually bad code written by Java transplants who haven't learned the right way to code C++. But that code has to run, too.

[surajrmal]

Almost but not always. Fuchsia saw 1% memory savings (~20MiB) by enabling it:

https://youtu.be/9HGKlDiJy8E

[Jyaif]

> Space for vtables is almost always negligible, especially so on 64-bit targets.

From the link: "I can report that a prototype of this was able to shrink Chromium's code size by 9%."

[ncmncm]

I bet that was pre-linked size. But that corroborates my expectation about Chrome code quality.

[pjmlp]

Before Java came into the world I remember Turbo Vision, Powerplant, CSet++, OWL, MFC, Motif++, VCL, Tools.h++,...