Bug 61771 – Unnecessary condition checks in HTMLTreeBuilder when not parsing fragment

• Status: RESOLVED
• Resolution: INVALID
• Component: WebCore Misc.

[Balazs Kelemen]

Let me give an example:
// FIXME: This is slow.
if (!m_tree.openElements()->inTableScope(tbodyTag.localName()) && !m_tree.openElements()->inTableScope(theadTag.localName()) && !m_tree.openElements()->inTableScope(tfootTag.localName())) {
    ASSERT(isParsingFragment());
    parseError(token);
    return;
}

In release builds there is no reason for evaluating the condition if not parsing fragment because it must never be true.

[Balazs Kelemen]

Created attachment 95406 [details]
patch

[Balazs Kelemen]

Comment on attachment 95406 [details]
patch

This does not work with expressions that have side effect. Need to revert such changes.

[Balazs Kelemen]

Created attachment 95432 [details]
Patch

[Adam Barth]

Comment on attachment 95432 [details]
Patch

Does this have a measurable effect on performance?  You can try using these benchmarks:

http://trac.webkit.org/browser/trunk/PerformanceTests/Parser

(Marking R- for now, but feel free to renominate.)

[Alexey Proskuryakov]

I'm not sure if adding the macro is so great. It suddenly exposes readers of the code to non-C++ syntax that's only used in this file. Learning a new syntax costs a lot!

[Balazs Kelemen]

No gain on the html5 parser test.