Virtual methods all over Gecko (Raptor, originally) really hurt. QI, AddRef/Release (nonsensical for arena-allocated objects, but the COM disease was rampant), all the core rendering object methods were virtual. De-virtualization took years.
KHTML (now WebKit) avoided this costly mistake. It's not the same as what's discussed here but I wanted to support the concern about indirect call overhead. It's not a premature optimization to consider at this juncture. /be On Dec 4, 2011, at 10:00 PM, Patrick Walton wrote: > On 12/04/2011 09:39 PM, Patrick Walton wrote: >> Strongly disagree. If we cannot inline stuff like map, we cannot create >> a performant browser engine. There is no way around this. > > I should elaborate: Short of just telling users they can't use the looping > abstractions in the standard library if they want performant loops, which > seems like a non-starter to me. I suspect that would just lead to systems > programmers writing loops by hand, using macros, using the C preprocessor, or > something like that. All of those options would result in relatively > unstructured workarounds that miss out on the benefits of the functional > abstractions we're offering. > > We already see high-profile projects like SQLite do so-called "unity builds" > where they concatenate everything into one enormous .c file. This is in spite > of the fact that C already has macros and static/inline functions. > > We could do measurements here with instrumenting rustc, but I'm not sure it > would be relevant. What would be more relevant would be something like > inserting two function calls (one direct, one indirect) around every pixel in > pixman's alpha blending routines and seeing what the performance of Firefox > becomes. But I think we already know what the results of this test would be. > > Sorry for wording this so strongly, but I feel that this is an important > issue. > > Patrick > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
