Re: [dev-servo] Handling adoptNode

2012-10-22 Thread Brendan Eich 

Boris Zbarsky wrote:

On 10/21/12 1:34 PM, Brendan Eich wrote:

Ah, ok.  We'd need to find all the places in the old document that
reference the node, but that might be feasible.


By tracking all the time, or scanning only upon an adoptNode? Hrm.


We'd only need the Rust references, since the JS ones would be handled 
by the brain transplant.


Also, in Rust there would be no references from the normal DOM.  And 
none from layout, as Patrick says.


Right, got that.

So we'd only need to worry about places in the Rust code on the DOM 
side that hold references to nodes that are not in the DOM tree.  
There shouldn't be that many (e.g. the -moz-element stuff would have 
that, perhaps, and things like image loads and whatnot), and we'd have 
to teach all of them about adoption.  Or do some sort of scan on 
adopt.  Or something.  Either way, in terms of perf the hit would be 
when adopting only.


Is adoptNode an important API? It's not a good design in my view, but 
I'm in a glass house when it comes to criticizing DOM APIs :-P. Perhaps 
it's ok for performance to be in a penalty box for adoptNode.


/be
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Handling adoptNode

2012-10-22 Thread David Bruant 
Le 22/10/2012 12:58, Brendan Eich a écrit :
> Boris Zbarsky wrote:
>> So we'd only need to worry about places in the Rust code on the DOM
>> side that hold references to nodes that are not in the DOM tree. 
>> There shouldn't be that many (e.g. the -moz-element stuff would have
>> that, perhaps, and things like image loads and whatnot), and we'd
>> have to teach all of them about adoption.  Or do some sort of scan on
>> adopt.  Or something.  Either way, in terms of perf the hit would be
>> when adopting only.
>
> Is adoptNode an important API? It's not a good design in my view, but
> I'm in a glass house when it comes to criticizing DOM APIs :-P.
> Perhaps it's ok for performance to be in a penalty box for adoptNode.
As a web developer, I've never used adoptNode, I don't even recall
having seen it in an actual website while view-sourcing. So if there is
a trade-off to be made in which the downside is adoptNode being slow, I
personnally think it's a worthwhile trade-off.

David
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Handling adoptNode

2012-10-22 Thread Benjamin Smedberg 

On 10/22/2012 7:59 AM, David Bruant wrote:

Is adoptNode an important API? It's not a good design in my view, but
I'm in a glass house when it comes to criticizing DOM APIs :-P.
Perhaps it's ok for performance to be in a penalty box for adoptNode.
As a web developer, I've never used adoptNode, I don't even recall
having seen it in an actual website while view-sourcing. So if there is
a trade-off to be made in which the downside is adoptNode being slow, I
personnally think it's a worthwhile trade-off.
It's definitely used on some high-visibility websites; we had a bug 
where some framework was calling .adoptNode on a plugin element and it 
showed up on several sites including a German transit site and several 
Chinese video sites. So I'd treat our assumptions with some caution.


I thought that using XHR to parse into a document and then adopting 
those nodes into the current document is a fairly common occurrence, but 
I might be wrong about that.


--BDS

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Handling adoptNode

2012-10-22 Thread Boris Zbarsky 

On 10/22/12 6:58 AM, Brendan Eich wrote:

Is adoptNode an important API?


Define important?

Not implementing adoption breaks the web.  That includes both explicit 
adoption via adoptNode and implicit adoption via simply inserting the 
node into a different document.  Both pose identical problems for our 
design, so I wasn't bothering to draw a distinction between them.



Perhaps it's ok for performance to be in a penalty box for adoptNode.


Yes.  There already is in Gecko, btw: we have to go through and 
brain-transplant everything in the subtree and whatnot.


-Boris

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Handling adoptNode

2012-10-22 Thread Brendan Eich 

Boris Zbarsky wrote:

On 10/22/12 6:58 AM, Brendan Eich wrote:

Is adoptNode an important API?


Define important?


Defined in terms of "not important" == "can put in perf penalty box" of 
some non-trivial penalty-size.


Still could have too high a penalty, but we can roll the dice with Servo.

/be



Not implementing adoption breaks the web.  That includes both explicit 
adoption via adoptNode and implicit adoption via simply inserting the 
node into a different document.  Both pose identical problems for our 
design, so I wasn't bothering to draw a distinction between them.



Perhaps it's ok for performance to be in a penalty box for adoptNode.


Yes.  There already is in Gecko, btw: we have to go through and 
brain-transplant everything in the subtree and whatnot.


-Boris

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Handling adoptNode

2012-10-22 Thread Boris Zbarsky 

On 10/22/12 7:59 AM, David Bruant wrote:

As a web developer, I've never used adoptNode


I will bet $100 that you have, and never even realized it, what with 
implicit adoption.  Again, unless you're narrowly defining "use" as 
"call adoptNode" as opposed to "adopt a node".


Specifically, compare 
 to step 7 of 
 or step 8 of 
.


So the tradeoff is that cross-document inserts are slower.  Which is 
fine, since they are rare.


-Boris
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Handling adoptNode

2012-10-22 Thread Boris Zbarsky 

On 10/22/12 10:15 AM, Brendan Eich wrote:

Defined in terms of "not important" == "can put in perf penalty box" of
some non-trivial penalty-size.


This is always true. It only takes one benchmark that takes off that 
exercises something you assumed was rare for you to be screwed.


That said, I would want the extra work done on adopt to be _small_. 
Scanning the whole heap, say, would NOT be acceptable.


-Boris
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Handling adoptNode

2012-10-22 Thread Brendan Eich 

Boris Zbarsky wrote:

On 10/22/12 10:15 AM, Brendan Eich wrote:

Defined in terms of "not important" == "can put in perf penalty box" of
some non-trivial penalty-size.


This is always true. It only takes one benchmark that takes off that 
exercises something you assumed was rare for you to be screwed.


Not quite a truism. We know document.write has to be fast 
(http://www.youtube.com/watch?v=3NVpFj64MQU). We don't know adoptNode 
has to be fast, and any new benchmark trying to "take off" (like 
SunSpider did when there was a vacuum in JS benchmarks) will face 
push-back, probably from multiple browser implementors.


That said, I would want the extra work done on adopt to be _small_. 
Scanning the whole heap, say, would NOT be acceptable.


Agreed. You wrote "(e.g. the -moz-element stuff would have that, 
perhaps, and things like image loads and whatnot)". Can we (heh, you 
rather than me) enumerate cases for Servo and rule out a general heap scan?


/be
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Handling adoptNode

2012-10-22 Thread Boris Zbarsky 

On 10/22/12 10:29 AM, Brendan Eich wrote:

We know document.write has to be fast
(http://www.youtube.com/watch?v=3NVpFj64MQU).


1)  document.write is not fast (though of course "fast" is a relative 
concept).

2)  How slow it is depends on what's passed to the call.

Just fyi.

This has nothing to do with adoptNode.


Agreed. You wrote "(e.g. the -moz-element stuff would have that,
perhaps, and things like image loads and whatnot)". Can we (heh, you
rather than me) enumerate cases for Servo and rule out a general heap scan?


The set of cases will depend on the exact web technologies, now and 
future, that Servo supports, and that's a moving target.


But basically, if you're holding a node pointer and you're not its 
parent/child/sibling, then obviously you'll need to deal with it being 
copied on adopt if that's what we're doing  The simplest way to deal 
is to use a helper of some sort to hold such pointers instead of holding 
raw pointers.


-Boris

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo