Closed Bug 1861010 Opened 2 years ago Closed 2 years ago

Improve HTML parser attribute name handling a bit.

Categories

(Core :: DOM: HTML Parser, task)

task

Tracking

()

RESOLVED FIXED

People

(Reporter: emilio, Assigned: emilio)

References

Details

Attachments

(5 files, 2 obsolete files)

We do a bit of inefficient stuff, mainly:

  • Lots of indirections.
  • For non-interned atoms, we end up doing three atom addrefs and releases when we only need one.
  • Some redundant hashing.

This seems to improve SP3 performance a bit in the innerHTML heavy bits, see here (though I need to admit I'm not sure what happened with the windows results)

Attached patch Java part 1 (obsolete) — Splinter Review
Attachment #9360203 - Flags: review?(hsivonen)
Attached patch Java part 2Splinter Review
Attachment #9360204 - Flags: review?(hsivonen)

I need to check whether we can remove the recently used atom stuff, but this
should be uncontroversial.

In particular:

  • Store local names, namespaces, etc inline.
  • Avoid taking unnecessary atom references for non-interned atoms.

As a follow-up, we can look into making the input data truly static,
which would be nice.

Depends on D191853

Attachment #9360203 - Attachment is obsolete: true
Attachment #9360203 - Flags: review?(hsivonen)
Attachment #9360209 - Flags: review?(hsivonen)
Attachment #9360209 - Attachment is patch: true
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/15de815b169e Avoid some duplicated string hashing in the html parser. r=smaug
Keywords: leave-open
Comment on attachment 9360209 [details] [diff] [review] Java part 1 (with minor typo / import fixes) Review of attachment 9360209 [details] [diff] [review]: ----------------------------------------------------------------- Seems believable. (I'll come back to this.) ::: translator-src/nu/validator/htmlparser/cpptranslate/CppVisitor.java @@ +1292,5 @@ > n.getArgs().get(0).accept(this, arg); > printer.print(".Release()"); > + } else if ("addrefIfNonNull".equals(n.getName()) > + && "Portability".equals(n.getScope().toString())) { > + printer.print("NS_IF_ADDREF("); Please put "NS_IF_ADDREF" and "NS_IF_RELASE" in `CppTypes`. A non-Gecko-flavored target has never emerged, but let's still keep this stuff parametrized there.
Comment on attachment 9360204 [details] [diff] [review] Java part 2 Review of attachment 9360204 [details] [diff] [review]: ----------------------------------------------------------------- I trust that this makes sense. rs+
Attachment #9360204 - Flags: review?(hsivonen) → review+
Comment on attachment 9360209 [details] [diff] [review] Java part 1 (with minor typo / import fixes) Review of attachment 9360209 [details] [diff] [review]: ----------------------------------------------------------------- r+ provided that the refcounting macros are parametrized via `CppTypes`. ::: translator-src/nu/validator/htmlparser/cpptranslate/CppVisitor.java @@ +1292,5 @@ > n.getArgs().get(0).accept(this, arg); > printer.print(".Release()"); > + } else if ("addrefIfNonNull".equals(n.getName()) > + && "Portability".equals(n.getScope().toString())) { > + printer.print("NS_IF_ADDREF("); Please put "NS_IF_ADDREF" and "NS_IF_RELASE" in `CppTypes`. A non-Gecko-flavored target has never emerged, but let's still keep this stuff parametrized there.
Attachment #9360209 - Flags: review?(hsivonen) → review+
Attachment #9360209 - Attachment is obsolete: true
Attachment #9360232 - Attachment description: Bug 1861010 - Avoid leaking on the nsHtml5AttributeName() constructor. r=hsivonen → Bug 1861010 - Avoid leaking on the nsHtml5AttributeName constructor. r=hsivonen
Pushed by nerli@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5ac17201cd79 Avoid leaking on the nsHtml5AttributeName constructor. rpending=hsivonen CLOSED TREE
Blocks: 1861068
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: