RESOLVED FIXED 86171
REGRESSION(r115142) webkit-patch rebaseline-expectations slow in non-pst timezones 
https://bugs.webkit.org/show_bug.cgi?id=86171
Summary REGRESSION(r115142) webkit-patch rebaseline-expectations slow in non-pst time...
noel gordon
Reported 2012-05-10 20:51:08 PDT
Time how long it takes to rebaseline one test from AEST timezone % time Tools/Scripts/webkit-patch -v rebaseline-expectations [snip ... see trace attached] real 21m13.831s user 0m13.924s sys 0m5.240s
Attachments
non-pst-webkit-patch-rebaseline-expectations.txt (34.24 KB, text/plain)
2012-05-10 20:52 PDT, noel gordon 		no flags
Details
webkit-patch-rebaseline-test-webkit-linux.txt (28.63 KB, text/plain)
2012-05-10 21:49 PDT, noel gordon 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
noel gordon
Comment 1 2012-05-10 20:52:33 PDT
Created attachment 141319 [details] non-pst-webkit-patch-rebaseline-expectations.txt
Eric Seidel (no email)
Comment 2 2012-05-10 21:21:47 PDT
Holy moly! That's *really* bad. Would you mind running one of the sub-commands with -v for me and posting the output? For example: /Users/noel/chromium/src/third_party/WebKit/Tools/Scripts/webkit-patch -v rebaseline-test Webkit Mac10.7 compositing/geometry/horizontal-scroll-composited.html
noel gordon
Comment 3 2012-05-10 21:48:31 PDT
Don't mind at all, ran ... % time Tools/Scripts/webkit-patch -v rebaseline-test "Webkit Linux" compositing/geometry/vertical-scroll-composited.html [snip trace attached] real 3m5.867s user 0m1.303s sys 0m0.582s
noel gordon
Comment 4 2012-05-10 21:49:40 PDT
Created attachment 141324 [details] webkit-patch-rebaseline-test-webkit-linux.txt
Eric Seidel (no email)
Comment 5 2012-05-10 22:49:45 PDT
Geeeeez! http://build.chromium.org/f/chromium/layout_test_results/Webkit_Linux/layout-test-results.zip is 34mb! And it looks like we're pulling it down for each run of rebaseline-test, which there may be many when running rebaseline-expectations!
Eric Seidel (no email)
Comment 6 2012-05-10 22:50:50 PDT
It's taking my internet connection like 8min to pull down that file. I'm not sure how rebaseline-test was ever supposed to work w/o caching. :(
Eric Seidel (no email)
Comment 8 2012-05-10 22:52:40 PDT
This is a huge regression from bug 84762.
Adam Barth
Comment 9 2012-05-11 00:38:46 PDT
I guess I'm late to the party and you all already figured this out.
Dirk Pranke
Comment 10 2012-05-11 10:43:26 PDT
Rollout of r115142 is posted in bug 86231 ... hopefully that'll make the performance closer to acceptable, at the potential cost (for now) of some correctness.
Dirk Pranke
Comment 11 2012-05-11 11:11:01 PDT
Hopefully this was fixed by http://trac.webkit.org/changeset/116787 . Let me know if it's still dog-slow.
noel gordon
Comment 12 2012-05-12 01:52:58 PDT
158 minutes for 101 tests, much better than 21 minutes per test.
Eric Seidel (no email)
Comment 13 2012-05-12 02:04:35 PDT
(In reply to comment #12) > 158 minutes for 101 tests, much better than 21 minutes per test. Wow! That's still *way* too slow. If you could file another bug with the -v output next time you do a big run. We should be able to make that much faster.
Note You need to log in before you can comment on or make changes to this bug.