Re: [webkit-dev] A proposal for Platform Mechanisms
From: da...@apple.com Date: Wed, 16 Jun 2010 17:55:10 -0700 To: ander...@apple.com CC: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] A proposal for Platform Mechanisms Sounds reasonable to me. We already follow pointers and use virtual functions for all these things, so I don’t see them adding a lot of overhead. Just to reiterate the problem I keep seeing is that it appears that the virtuals are not the problem as much as where the pointers finally point. That is, so ok you can inline all your pointer getters but if someone collects a bunch of widget pointers and they point to different pages in VM and then they keep accessing them in random orders, it is likely to create problems. This is my current concern since I no longer seem to be able to fill out forms without the !#$!# disk light coming on for 10s of seconds at a time and no chars being echoed in the meantime. While a ctor maybe an order zero thing, uses of the object will be fast or slow depending on what that does to the memory situation. I'm not sure I have a specific suggestion that relates to this immediate issue other than be aware of the potential and real concerns and perhaps making getter users write inner loops that are coherent and simple and finally blocking them to preserve cache coherence, not just VM. ( and avoiiding runon sentences leads to less coherences that is harder to read, you get the pointer LOL). Would these Mechanism classes replace all the current Client classes? Would the mechanism objects be obtained once and cached globally? How is the initial PlatformMechanism object created? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A proposal for Platform Mechanisms
On Jun 16, 2010, at 8:34 PM, Darin Fisher wrote:
Hi, this is of course a very interesting topic!
Yes, and I really appreciate your feedback on this!
Some comments:
1- Why do you see the need for these interfaces to be virtual? Will there be
multiple implementations?
Some possible answers that come to mind:
a) Yes, there could be a proxy implementation used to marshal calls to the
real implementation that lives in the main process. Both should implement
the same interface.
b) Just following the {Chrome,FrameLoader,*}Client convention.
c) So that WebCore can still be built as a DLL/DYLIB.
Mostly a) and c). This is correct. For current WebKit, we won't have a proxy
implementation, but for WebKit2 we will. We'd like both of these WebKit
frameworks to be able to use the same WebCore framework.
2- This looks a lot like WebKitClient in the Chromium WebKit API, except that
WebKitClient is defined at the API layer and not at the WebCore/platform
layer. Related point: WebCore::ChromiumBridge is just a bunch of static
functions because it seems wasteful to define intermediate virtual functions
at the WebCore level. Note: There is a plan to rename ChromiumBridge to
PlatformBridge because the Android port wishes to share some of the same
infrastructure. There is already a typedef in place.
These functions are virtual because they are intended to be implemented by
WebKit. Also, none of these functions are really called that often (and if they
ever are, we should consider caching the result or other performance fixes).
3- Not all of the WebCore/platform classes are well suited for a
straightforward delegation. In some cases, delegation back through
ChromeClient is actually better. See the extra methods on
ChromeClientChromium, which extends ChromeClient. I believe that at least a
few methods on ChromiumBridge should be re-routed in this manner.
I definitely agree that we shouldn't just pile things on to these new classes.
(I also don't see why the ChromeClientChromium functions couldn't be added to
ChromeClient directly).
4- There are numerous concrete types (e.g., for cursors, icons, images, etc.)
that end up being defined very differently at the port layer for a
multi-process port. This may be a non-factor though, but perhaps we should
think about how to share these definitions too.
As we move forward and get more and more of WebKit2 in place, this will
definitely be something to think about.
Thanks for your feedback!
- Anders
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)
On 16 Jun 2010, at 23:12, David Hyatt wrote: On Jun 14, 2010, at 7:00 PM, Matt 'Murph' Finnicum wrote: Why are there so many Text nodes in the DOM? I had a look at the initial DOM tree from rendering slashdot, and there are 1959 Text nodes. Of those 1959, 1246 were whitespace-only nodes. Does there need to be this many nodes? Why can't whitespace be combined with the nodes next to it? Whitespace nodes most commonly occur between elements, so they can't be coalesced. Hmm, this touches on a very interesting topic... Strictly speaking, a basic parser, be it XML or HTML, should never, ever report anything to downstream consumers that was not in the original source document. The software is doing its job pretty accurately in that respect. All it needs is a little help from the consumer/user/developer. --Think JS minifying. This saves on bandwidth and even, IIRC, makes the compiler's job easier. Basically, almost all of that whitespace serves only one purpose: to make the source human-readable. All well while you're developing a website or webapp, but come deployment, you will always fare better if the input stream is guaranteed to be processor-friendly to begin with. Less ghosts to chase. If the input is at least XHTML, and one is a tiny bit versed in XSLT, adding a preprocessing whitespace stripper stylesheet could be a quick-fix solution to reduce the waste of resources. That does consume resources elsewhere, obviously, so you may want to check if it's really worth the effort. xml:space, you would get for free if the processor is compliant in that respect. For the remainder, basically a plain copy template for all nodes. The exception being text nodes, for which you can use normalize-space() to see if they contain anything other than XML whitespace, and thus need copying. The limitation is that you do not have access to the resolved CSS, IIC. In other words, if you have elements that can have #PCDATA content and that get a class assigned that sets properties related to whitespace preservation, the XSLT stylesheet will not see it (although there may exist extensions for CSS parsing, not sure). Then again, whitespace within, before or after text nodes is no problem, since that is presumed significant by default (but that gets coalesced with the other text later on, so no issue at all). Part of it could, maybe, remotely, be implemented in WebKit itself. If WebKit chooses, for example, to ignore character events from the parser in nodes where logically it doesn't make sense to have stray characters (which, incidentally, is the strategy Apache FOP uses, but that may be a slightly different story since that is pure XML), it could mean a significant reduction of the above 1246 nodes... perhaps even to 0? Downsides? The live DOM no longer *exactly* reflects the input, so it would definitely need to be configurable, just in case one does need that functionality. OTOH, let's say that 95% of a site's visitors is not interested at all in what the HTML source looks like. If you really want to share your code with the other 5%, there are far better ways to do that than relying on 'View Source', no? For the remainder, I must admit I am having a hard time imagining scenarios where ignorable whitespace would be desirable to keep around. In the worst case, it could even needlessly complicate certain layout- and rendering-related tasks... Regards, Andreas Delmelle --- ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A proposal for Platform Mechanisms
On Thu, Jun 17, 2010 at 9:47 AM, Anders Carlsson ander...@apple.com wrote:
On Jun 16, 2010, at 8:34 PM, Darin Fisher wrote:
Hi, this is of course a very interesting topic!
Yes, and I really appreciate your feedback on this!
Some comments:
1- Why do you see the need for these interfaces to be virtual? Will
there be multiple implementations?
Some possible answers that come to mind:
a) Yes, there could be a proxy implementation used to marshal calls to
the real implementation that lives in the main process. Both should
implement the same interface.
b) Just following the {Chrome,FrameLoader,*}Client convention.
c) So that WebCore can still be built as a DLL/DYLIB.
Mostly a) and c). This is correct. For current WebKit, we won't have a
proxy implementation, but for WebKit2 we will. We'd like both of these
WebKit frameworks to be able to use the same WebCore framework.
Makes sense. By the way, there are more modules other than WebCore/platform
that will require this kind of separation. WebCore/storage has several
examples of this. Jorlow already modified the LocalStorage implementation
to support this kind of separation. It'd be nice if whatever model is
adopted for WebCore/platform can also be applied to these other modules.
(Doesn't sound like it will be an issue.)
2- This looks a lot like WebKitClient in the Chromium WebKit API, except
that WebKitClient is defined at the API layer and not at the
WebCore/platform layer. Related point: WebCore::ChromiumBridge is just a
bunch of static functions because it seems wasteful to define intermediate
virtual functions at the WebCore level. Note: There is a plan to rename
ChromiumBridge to PlatformBridge because the Android port wishes to share
some of the same infrastructure. There is already a typedef in place.
These functions are virtual because they are intended to be implemented by
WebKit. Also, none of these functions are really called that often (and if
they ever are, we should consider caching the result or other performance
fixes).
It's not so much about performance. There's a cognitive cost to having so
many layers. But, given (c) above, I understand that you really don't have
a choice. In contrast, the Chromium project doesn't build WebCore as a
standalone DLL, so we don't have the same constraint. I don't have a
problem replacing ChromiumBridge / PlatformBridge with a virtual table (or a
set of virtual tables) if that means that we can share more code with other
ports.
3- Not all of the WebCore/platform classes are well suited for a
straightforward delegation. In some cases, delegation back through
ChromeClient is actually better. See the extra methods on
ChromeClientChromium, which extends ChromeClient. I believe that at least a
few methods on ChromiumBridge should be re-routed in this manner.
I definitely agree that we shouldn't just pile things on to these new
classes. (I also don't see why the ChromeClientChromium functions couldn't
be added to ChromeClient directly).
I think they can be moved to ChromeClient. ChromeClientChromium was created
to avoid adding things to ChromeClient that were Chromium specific. Maybe
some of those things will no longer be Chromium specific going forward.
4- There are numerous concrete types (e.g., for cursors, icons, images,
etc.) that end up being defined very differently at the port layer for a
multi-process port. This may be a non-factor though, but perhaps we should
think about how to share these definitions too.
As we move forward and get more and more of WebKit2 in place, this will
definitely be something to think about.
Thanks for your feedback!
I'd definitely like to see how we can work together on some of this stuff.
It will mean less disparity between our ports.
-Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)
On Jun 17, 2010, at 2:45 PM, Gustavo Sverzut Barbieri wrote: David, it's bit more than annoying, it's fragmenting memory for no good. In the long run on systems will small memory it does make a difference :-/ I'd like to see some option, maybe compile-time, to strip these useless whitespaces. As Alexey points out, this is a compatibility issue though. People write code assuming the whitespace nodes are there. If you remove them, you'll see Web site breakage. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)
On Thu, Jun 17, 2010 at 4:19 PM, David Hyatt hy...@apple.com wrote: On Jun 17, 2010, at 2:45 PM, Gustavo Sverzut Barbieri wrote: David, it's bit more than annoying, it's fragmenting memory for no good. In the long run on systems will small memory it does make a difference :-/ I'd like to see some option, maybe compile-time, to strip these useless whitespaces. As Alexey points out, this is a compatibility issue though. People write code assuming the whitespace nodes are there. If you remove them, you'll see Web site breakage. dave (hy...@apple.com) Do people write code assuming the content of the whitespace nodes? That seems very unlikely to me. If not, we could collapse them and be much more efficient about things (such as a simple flag in their parent node that represents their existence) --Murph ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)
On Thu, Jun 17, 2010 at 6:24 PM, Matt 'Murph' Finnicum mattf...@gmail.com wrote: On Thu, Jun 17, 2010 at 4:19 PM, David Hyatt hy...@apple.com wrote: On Jun 17, 2010, at 2:45 PM, Gustavo Sverzut Barbieri wrote: David, it's bit more than annoying, it's fragmenting memory for no good. In the long run on systems will small memory it does make a difference :-/ I'd like to see some option, maybe compile-time, to strip these useless whitespaces. As Alexey points out, this is a compatibility issue though. People write code assuming the whitespace nodes are there. If you remove them, you'll see Web site breakage. dave (hy...@apple.com) Do people write code assuming the content of the whitespace nodes? That seems very unlikely to me. If not, we could collapse them and be much more efficient about things (such as a simple flag in their parent node that represents their existence) Same experience on my side, most JS libs that handle whitespace, do it just to ignore the nodes... running through strip and then checking for emptiness. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)
On Jun 17, 2010, at 4:07 PM, Eric Seidel wrote: A does not follow from B in that sentence, that current memory fragmentation means we need to strip whitespace nodes. Yeah exactly. Let's see some measurements that show the presence of these nodes are a real problem. It would also be possible to create a special shared \n text node, and have some sort of Copy On Write behavior. Again, more complexity. Not sure if the complexity would be worth the perf win. There might be interesting tricks around this idea yeah. Basically you want the common case of never really looking at the DOM from JS to result in efficient performance/memory use. If walking the DOM then results in the creation of a more heavyweight whitespace Node, that would be fine I think. The idea of trying to fold the information into Element is an interesting one. Again I think we'd need measurements to see how much of a gain we'd typically get if we did this just for newlines for example, or if we'd need an optimization that extended to arbitrary whitespace sequences. I tend to think the latter would be required (since cleanly indented HTML will have newlines and tabs and spaces for indentation in between elements). I'm not particularly interested in a break-the-web mode that strips out those Nodes completely by default, since (a) breaking compatibility is bad and (b) nobody has shown me any evidence that these extra nodes are a problem on mobile devices. An optimization that reduces memory use while preserving the correct behavior is much more appealing to me. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)
I have seen sites that make this assumption. Even worked on one. From a website writer's view, the whitespace nodes are usually a pain, but if you add some hacks to skip around them (as ugly as that is), you expect those hacks to keep working. trey On Jun 17, 2010, at 2:19 PM, David Hyatt wrote: On Jun 17, 2010, at 2:45 PM, Gustavo Sverzut Barbieri wrote: David, it's bit more than annoying, it's fragmenting memory for no good. In the long run on systems will small memory it does make a difference :-/ I'd like to see some option, maybe compile-time, to strip these useless whitespaces. As Alexey points out, this is a compatibility issue though. People write code assuming the whitespace nodes are there. If you remove them, you'll see Web site breakage. dave (hy...@apple.com) ___ 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
Re: [webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)
I filed https://bugs.webkit.org/show_bug.cgi?id=40800 to track this issue. I think we can take further discussion to the bug. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
