https://perf.webkit.org/#mode=charts&chartList=%5B%5B%22mac-mountainlion%22%2C%22Dromaeo%2Fcssquery-dojo%3ARuns%22%5D%2C%5B%22mac-mountainlion%22%2C%22Dromaeo%2Fcssquery-jquery%3ARuns%22%5D%2C%5B%22mac-lion%22%2C%22Dromaeo%2Fcssquery-jquery%3ARuns%22%5D%5D&days=136&zoom=%5B1381314242746.7024%2C1382083568577.5894%5D http://trac.webkit.org/log/?rev=157355&stop_rev=157354&verbose=on
r157355 was supposed to just be a refactoring and should not have had any performance impact.
I re-read http://trac.webkit.org/changeset/157355 and I can’t spot any change that should have had performance impact.
I think <http://trac.webkit.org/changeset/157354> is the likely culprit here.
I guess I misunderstood the title of the bug. I assumed it meant that r157354 was known to fast and r157355 was known to be slow.
r157354 was supposed to just be a refactoring and should not have had any performance impact. I re-read http://trac.webkit.org/changeset/157354 and I can’t spot any change that should have had performance impact.
This regression is hardly noticeable on my local machine so it could be something to do with memory alignment and the order file.
CSS Query r157352: http://dromaeo.com/?id=212262 8429.08runs/s (Total) DOM Query (Dojo): 7327.92runs/s DOM Query (ExtJS): 5174.90runs/s DOM Query (Mootools): 11909.97runs/s DOM Query (Prototype): 9965.06runs/s DOM Query (Yahoo UI): 5969.95runs/s DOM Query (jQuery): 13193.79runs/s r157355: http://dromaeo.com/?id=212266 8484.89runs/s (Total) DOM Query (Dojo): 7488.50runs/s DOM Query (ExtJS): 5400.73runs/s DOM Query (Mootools): 11823.50runs/s DOM Query (Prototype): 9950.53runs/s DOM Query (Yahoo UI): 5940.33runs/s DOM Query (jQuery): 13064.93runs/s I guess the change is with in the margin of errors here :(