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 ([email protected]) _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
