[webkit-dev] SharedWorkers alternate design

[David Levin]

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 <jorlow at 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 <jam at google.com> wrote:
>
>>
>>
>> On Tue, May 26, 2009 at 5:31 PM, Jeremy Orlow <jorlow at chromium.org>wrote:
>>
>>> On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow <jorlow at chromium.org>wrote:
>>>
>>>> On Tue, May 26, 2009 at 5:05 PM, Sam Weinig <sam.weinig at gmail.com>wrote:
>>>>
>>>>> On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow <jorlow at 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/52b38f6e/attachment-0001.html>