I think the principle is simple "classes that can avoid virtuals should." There are lots of tricky situations, but in general make a good effort to avoid virtual methods (which to me means be prepared to answer why you *need * a virtual method in a given place).
By avoid them, there isn't a question of whether the virtuals are affecting performance (in any way -- making inlining impossible, adding to program size, messing with branch prediction, etc.) Sometimes great perf is due to one cool algorithm, but a lot of times it is also due to a thousand little things. dave On Tue, May 26, 2009 at 7:23 PM, Jeremy Orlow <jor...@chromium.org> wrote: > It might also be worth bringing back up the unanswered quesiton of whether > this is even worth it for AppCache and LocalStorage. As I mentioned, my > (less than scientific) testing indicated no.* Maybe we're prematurely > optimizing here? I definitely agree that virtual functions should be > avoided in code that's often called, but even AppCache doesn't really seem > to fit into that category. > > Jeremy > > * I have a test page that calls window.localStorage 100,000 times, > localStorage.setItem(foo, bar) 100,000 times, and localStorage.getItem(foo) > 1,000,000 times. All of these take under half a second, and the times don't > really change with my new implementation which does use virtual dispatch. > > > > On Tue, May 26, 2009 at 7:00 PM, John Abd-El-Malek <j...@google.com> wrote: > >> >> >> On Tue, May 26, 2009 at 5:31 PM, Jeremy Orlow <jor...@chromium.org>wrote: >> >>> On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow <jor...@chromium.org>wrote: >>> >>>> On Tue, May 26, 2009 at 5:05 PM, Sam Weinig <sam.wei...@gmail.com>wrote: >>>> >>>>> On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow <jor...@chromium.org>wrote: >>>>> >>>>>> The common case is definitely that we know whether we want the proxy >>>>>> (for IPC) or the implementation at compile time. In some cases (like >>>>>> Chromium) this is not known until initialization time. >>>>> >>>>> >>>>> What do you mean by "initialization time"? Is it the case that you >>>>> know which one you want at each call site? Or do literally want to make a >>>>> runtime choice based on state? >>>>> >>>> >>>> Well, I meant that we always want one or the other based on if the >>>> process is being used as a render process (i.e. sandboxed, running WebKit >>>> but with all DOM Storage calls proxied) or a browser process (i.e. running >>>> only selected parts of WebCore like the DOM Storage >>>> backend/implementation). >>>> >>>> >>>> Come to think of it (IIRC) all calls to the StorageBackend within the >>>> WebCore code should go through a proxy for Chromium. The proxy will then >>>> call into Chromium's webkit bridge/glue, which will pass the message >>>> through >>>> the IPC layer, which will call back into bridge/glue code, which will be >>>> interacting with the real implementation. >>>> >>>> If that's true, then the implementation could be very explicitly split >>>> into 2 (with frontend code calling backend proxy code and vice versa) and >>>> single process implementations could simply typedef _____Proxy to _____Impl >>>> (or Implementation, or Base, or whatever you want to call it). >>>> >>>> ....or have I completely confused myself? >>>> >>> >>> To clarify, I'm saying that your question made me realize that we >>> probably can make a hard split between the frontend and backend code (i.e. >>> what would live in a sandbox and handle page rendering and what wouldn't >>> live in a sand box and store the actual DOM Storage data). In single >>> process cases where there is no IPC barrier, and thus no proxy (and thus the >>> actual implementation code should be called directly) a typedef should >>> bridge the 2 with no run time performance penalty. >>> >>> Darin, Sam, Maciej: does this alleviate your concerns? >>> >>> Michael, Drew, John: do you think it'd work for workers/appcache as well? >> >> >> This will work fine for appcache and localstorage, but isn't sufficient >> for workers since the same caller gets different objects depending on which >> process this is running in. This doesn't happen for appcache and >> localstorage. >> >> >>> >>> >>> Everyone: have I completely missed something here? >>> >>> J >>> >> >> > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev