1414178 - Find a better way instead of iterate the candidates array and remove the element from the array

Status: RESOLVED DUPLICATE of bug 1452074

(Core :: DOM: Core & HTML, enhancement, P2)

Description

[John Dai[:jdai]]

This is a follow-up of bug 1406325. If it's a performance cliff for custom element, we need to find a better way to improve performance. 
 
::: dom/base/CustomElementRegistry.cpp
@@ +327,5 @@
> +{
> +  nsTArray<nsWeakPtr>* candidates;
> +  if (mCandidatesMap.Get(aTypeName, &candidates)) {
> +    MOZ_ASSERT(candidates);
> +    for (size_t i = 0; i < candidates->Length(); ++i) {

We iterate the candidates array and remove the element from the array whenever an unresolved custom element is removed from tree. It looks like a bit expensive to me. It would be good if we could think about "is it possible to do something different to improve the performance", but this could be done on a separated bug, IMO.

Comment 1

[John Dai[:jdai]]

We can introduce a 'UnresolvedElementIsDirty' in custom element data and mark a custom element is dirty when the element is removed from tree and reset the dirty bit when the element add back to tree. Also, UpgradeCandidates need to skip the element which is marked by dirty.

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

CE general performance issues (I meant, when a page isn't using CE specific features) are much improved in bug 1410536. We should keep tuning CE performance for that a page uses CE features. John, please help this.

Comment 3

[John Dai[:jdai]]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #2)
> CE general performance issues (I meant, when a page isn't using CE specific
> features) are much improved in bug 1410536. We should keep tuning CE
> performance for that a page uses CE features. John, please help this.

Sure, I'll working on this.

Comment 4

[Edgar Chen [:edgar]]

Attachment: test.html

This is a test script that shows the slowness.

Comment 5

[Edgar Chen [:edgar]]

(In reply to John Dai[:jdai] from comment #1)
> We can introduce a 'UnresolvedElementIsDirty' in custom element data and
> mark a custom element is dirty when the element is removed from tree and
> reset the dirty bit when the element add back to tree. Also,
> UpgradeCandidates need to skip the element which is marked by dirty.

We need to be careful about the adoption case, for example,
1. create a custom element, <x-foo>, and append it to document A.
3. adopt and append <x-foo> into iframe document B.
4. register custom element definition for <x-foo> to the CustomElementRegistry of document A.
5. the custom element, <x-foo>, created in step 1 should not be upgraded.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

We can possibly optimize the code a bit more, but at least the worst case scenario should be fixed.