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