3 ms·
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 matter
by ncmncm 4y ago
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 4y agoAlmost but not always. Fuchsia saw 1% memory savings (~20MiB) by enabling it: https://youtu.be/9HGKlDiJy8E https://youtu.be/9HGKlDiJy8E
- pjmlp 4y agoBefore Java came into the world I remember Turbo Vision, Powerplant, CSet++, OWL, MFC, Motif++, VCL, Tools.h++,...
- Jyaif 4y ago> 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 4y agoI bet that was pre-linked size. But that corroborates my expectation about Chrome code quality.