482920 - [HTML5] Make all tokenizer state transitions use goto

Status: RESOLVED WONTFIX

(Core :: DOM: HTML Parser, defect, P4)

Description

[Henri Sivonen (:hsivonen)]

Need to make the Java to C++ translator recognize tokenizer state transitions and generate direct gotos for every transition. Then, suspension code needs to actually write the state variable so that continuing tokenization can be bootstrapped with switch.

Comment 1

[Henri Sivonen (:hsivonen)]

Try server shows me a 1% improvement on 64-bit Linux and Mac. Need to retest innerHTML stress tests. (Also need to re-run tp4 on try to be able to see if the 1% improvement is random.)

Comment 2

[Henri Sivonen (:hsivonen)]

(In reply to comment #1)
> Try server shows me a 1% improvement on 64-bit Linux and Mac.

That's 64-bit Linux and 64-bit Mac.

(Also, in case anyone is wondering about the greater improvement I mentioned on IRC earlier, that "improvement" was due to bugs in an earlier patch.)

Comment 3

[Henri Sivonen (:hsivonen)]

I tried 32-bit and 64-bit Linux builds on 64-bit Linux loading the HTML5 spec from the local SSD disk setting html { display: none: }, removing external stylesheets, removing image URLs and using /*...*/ comments to take out inline scripts and styles.

The results I get for the two variants of fixes I have for this bug show that in this case, the differences between builds are of the same magnitude as differences between loads in any one of the builds.

I also tried a totally contrived case of setting innerHTML on a non-displayed element to a very long string of markup. In that case, using goto was slightly worse with 64-bit builds and slightly better with 32-bit builds on both Mac and Linux (trying both 32-bit ad 64-bit builds on 64-bit OSs). However, the test case didn't represent any particular real-world case.

It seems to me that the Tp4 numbers should be re-run a few times. If we can get a consistent Tp4 win of 1% on some platforms, then it might be worthwhile to fix this.

Otherwise, this might not really matter either way.

Comment 4

[Henri Sivonen (:hsivonen)]

Since this isn't always a win and the win is small when there is a win, I'm going ahead and WONTFIXing this, since the added complexity doesn't seem to be justified.

It would be nice to profile this to exhaustion to understand why this isn't always a win, but I think it makes more sense to cut the losses than to spend more time on this.

Comment 5

[Henri Sivonen (:hsivonen)]

Attachment: The all-goto patch for Bugzilla archeologists

Comment 6

[Henri Sivonen (:hsivonen)]

Attachment: The patch on top of the goto patch that restores the reconsume variable