<div>I think the principle is simple &quot;classes that can avoid virtuals should.&quot;  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 <b>need</b> a virtual method in a given place).</div>
<div><br></div>By avoid them, there isn&#39;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.) <div><br>
</div><div>Sometimes great perf is due to one cool algorithm, but a lot of times it is also due to a thousand little things.<div><div><div><br></div><div><div>dave</div><div><br></div><div><div><div class="gmail_quote">On Tue, May 26, 2009 at 7:23 PM, Jeremy Orlow <span dir="ltr">&lt;<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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&#39;re prematurely optimizing here?  I definitely agree that virtual functions should be avoided in code that&#39;s often called, but even AppCache doesn&#39;t really seem to fit into that category.<br>

<br>Jeremy<br><br>* 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&#39;t really change with my new implementation which does use virtual dispatch.<div>
<div></div><div class="h5"><br>
<br><br><div class="gmail_quote">On Tue, May 26, 2009 at 7:00 PM, John Abd-El-Malek <span dir="ltr">&lt;<a href="mailto:jam@google.com" target="_blank">jam@google.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">

<br><br><div class="gmail_quote"><div><div></div><div>On Tue, May 26, 2009 at 5:31 PM, Jeremy Orlow <span dir="ltr">&lt;<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<div><div></div><div><div class="gmail_quote">On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow <span dir="ltr">&lt;<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<div><div></div><div><div class="gmail_quote">On Tue, May 26, 2009 at 5:05 PM, Sam Weinig <span dir="ltr">&lt;<a href="mailto:sam.weinig@gmail.com" target="_blank">sam.weinig@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<div class="gmail_quote"><div>On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow <span dir="ltr">&lt;<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">





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. </blockquote><div><br></div>





</div><div> What do you mean by &quot;initialization time&quot;?  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?<br></div></div></blockquote>




</div><br></div></div>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).<br>




<br><br>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&#39;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.<br>




<br>If that&#39;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).<br>




<br>....or have I completely confused myself?<br></blockquote></div><br></div></div>To clarify, I&#39;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&#39;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.<br>



<br>Darin, Sam, Maciej: does this alleviate your concerns?<br><br>Michael, Drew, John: do you think it&#39;d work for workers/appcache as well?</blockquote><div><br></div></div></div><div>This will work fine for appcache and localstorage, but isn&#39;t sufficient for workers since the same caller gets different objects depending on which process this is running in.  This doesn&#39;t happen for appcache and localstorage.</div>

<div>
<div> </div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><br><br>Everyone: have I completely missed something here?<br><font color="#888888"><br>

J<br>
</font></blockquote></div></div><br>
</blockquote></div><br>
</div></div><br>_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
<br></blockquote></div><br></div></div></div></div></div></div>