148 dombuilder thread fix

[rschwietzke]

Addresses #148 but also requires an update to HtmlUnit. See the other pull request there.
I tried to keep HTMLElements as close to the original patterns for compatibility as possible, but I cannot guarantee it.

[rbri]

@rschwietzke at the moment i think about a different approach - do we really need that cache?

Have hacked a bit to hopefully make the search for the elements a bit faster https://github.com/HtmlUnit/htmlunit-neko/commits/faster_elements/ - what do you think?

[rschwietzke]

Here are some quick results based on https://github.com/rschwietzke/htmlunit-benchmark/pull/new/HtmlELements-benchmark

mvn clean verify; java -Xms4g -Xmx4g -XX:+AlwaysPreTouch -jar target/benchmarks.jar "HtmlUnitBenchmark"
On a AMD Hetzner 8-core machine.

Original HtmlUnit 4.16 and Neko 4.16

Benchmark                 Mode  Cnt        Score   Error  Units
HtmlUnitBenchmark.simple  avgt    2  6,197,562.056          ns/op

Benchmark                                    Mode  Cnt          Score   Error   Units
HtmlUnitBenchmark.simple                     avgt    2  6,195,930.247           ns/op
HtmlUnitBenchmark.simple:gc.alloc.rate       avgt    2        976.941          MB/sec
HtmlUnitBenchmark.simple:gc.alloc.rate.norm  avgt    2  6,347,327.274            B/op
HtmlUnitBenchmark.simple:gc.count            avgt    2          9.000          counts
HtmlUnitBenchmark.simple:gc.time             avgt    2        518.000              ms

rschwietzke HtmlUnit 4.16 and Neko 4.16 with #148 PR

Benchmark                 Mode  Cnt        Score   Error  Units
HtmlUnitBenchmark.simple  avgt    2  5,995,492.787          ns/op

Benchmark                                    Mode  Cnt          Score   Error   Units
HtmlUnitBenchmark.simple                     avgt    2  5,885,584.865           ns/op
HtmlUnitBenchmark.simple:gc.alloc.rate       avgt    2       1030.254          MB/sec
HtmlUnitBenchmark.simple:gc.alloc.rate.norm  avgt    2  6,358,130.309            B/op
HtmlUnitBenchmark.simple:gc.count            avgt    2          9.000          counts
HtmlUnitBenchmark.simple:gc.time             avgt    2        514.000              ms

HtmlUnit 4.16 and Neko 4.16 with branch faster-elements

Benchmark                 Mode  Cnt        Score   Error  Units
HtmlUnitBenchmark.simple  avgt    2  6,360,979.112          ns/op

Benchmark                                    Mode  Cnt          Score   Error   Units
HtmlUnitBenchmark.simple                     avgt    2  6,435,120.453           ns/op
HtmlUnitBenchmark.simple:gc.alloc.rate       avgt    2       1001.726          MB/sec
HtmlUnitBenchmark.simple:gc.alloc.rate.norm  avgt    2  6,759,637.034            B/op
HtmlUnitBenchmark.simple:gc.count            avgt    2          9.000          counts
HtmlUnitBenchmark.simple:gc.time             avgt    2        543.000              ms

So I would favor my solution, also because of little less memory per operation. Hope that your HtmlUnit and mine are not off by that much.

[rschwietzke]

If you like, you can prepare two branches of HtmlUnit which pulls in the different Nekos to ensure we talk about the same. But I already tried that when running and bulding on the test machine.

[rschwietzke]

By the way, my rework was not designed to be faster, just safer in usage and threading. The different runtime comes for free by accident.