Bugzilla

Nice.

So as for some general context here: the basic path of this microbenchmark is to generate a huge number of selectors which can all be trivially rejected with the bloom filter (looking up a precomputed hash in an array).

The rejection happens at [1], so it's possible that's gotten slower somehow. It's also worth noting that I found this test to be very sensitive to the size of the Rule [2] struct, since that's the type in the giant array that we're iterating over when matching, and thus making it smaller increases the number of matches we can perform on a cache line before the next miss. It seems unlikely that xLTO would impact memory layout, but it's certainly an angle to consider.

[1] https://searchfox.org/mozilla-central/rev/38c88cbf4be87dfa0636d15a5d3599a8ea0d1a72/servo/components/selectors/matching.rs#196
[2] https://searchfox.org/mozilla-central/source/servo/components/style/stylist.rs#2278

Nice.

So as for some general context here: the basic path of this microbenchmark is to generate a huge number of selectors which can all be trivially rejected with the bloom filter (looking up a precomputed hash in an array).

The rejection happens at [1], so it's possible that's gotten slower somehow. It's also worth noting that I found this test to be very sensitive to the size of the Rule [2] struct, since that's the type in the giant array that we're iterating over when matching, and thus making it smaller increases the number of matches we can perform on a cache line before the next miss. It seems unlikely that xLTO would impact memory layout, but it's certainly an angle to consider.

[1] https://searchfox.org/mozilla-central/rev/38c88cbf4be87dfa0636d15a5d3599a8ea0d1a72/servo/components/selectors/matching.rs#196
[2] https://searchfox.org/mozilla-central/rev/38c88cbf4be87dfa0636d15a5d3599a8ea0d1a72/servo/components/style/stylist.rs#2278