Closed Bug 1414178 Opened 7 years ago Closed 6 years ago

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

Categories

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

enhancement

Tracking

()

RESOLVED DUPLICATE of bug 1452074

People

(Reporter: jdai, Unassigned)

References

Details

Attachments

(1 file)

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.
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.
Priority: -- → P2
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.
Assignee: nobody → 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.
Attached file test.html
This is a test script that shows the slowness.
(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.
Assignee: jdai → nobody
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
We can possibly optimize the code a bit more, but at least the worst case scenario should be fixed.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: