Bug 107988

Summary: [Mac] Pixel-based tests are run in a computationally inefficient way
Product: WebKit Reporter: Benjamin Poulain <benjamin>
Component: Tools / TestsAssignee: Benjamin Poulain <benjamin>
Status: RESOLVED LATER    
Severity: Normal CC: abarth, dpranke, eric, rniwa, sam, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch none

Benjamin Poulain
Reported 2013-01-25 15:34:13 PST
Ref-tests and Pixel-tests are slow for bad reasons.
Attachments
Patch (104.73 KB, patch)
2013-01-25 16:12 PST, Benjamin Poulain 		no flags
DetailsFormatted DiffDiff
Patch (104.45 KB, patch)
2013-01-25 16:57 PST, Benjamin Poulain 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Benjamin Poulain
Comment 1 2013-01-25 16:12:56 PST
Created attachment 184835 [details] Patch
Benjamin Poulain
Comment 2 2013-01-25 16:57:32 PST
Created attachment 184840 [details] Patch
Benjamin Poulain
Comment 3 2013-01-26 01:23:05 PST
Comment on attachment 184840 [details] Patch Taking this out of the queue. On my laptop, this makes the tests run slower than the old code. The reason is the overhead of transferring more bytes is higher than the cost of compressing the image (the speed of the RAM and smaller CPU caches likely explain why it varies). A solution to that would be to use shared memory instead of transferring everything over a pipe. Python and new-run-webkit-test have their load of problems, I am not sure what to do :(
Benjamin Poulain
Comment 4 2013-01-28 17:55:06 PST
That will have to wait :(
Dirk Pranke
Comment 5 2013-01-29 12:32:54 PST
This may not be that helpful, but I would expect that if your pixel results were up-to-date (and passed with --tolerance=0), this would be much less of an issue, since we don't actually send the image data back from DRT to NRWT when the image hashes match. Does that make sense?
Benjamin Poulain
Comment 6 2013-01-29 13:36:37 PST
(In reply to comment #5) > This may not be that helpful, but I would expect that if your pixel results were up-to-date (and passed with --tolerance=0), this would be much less of an issue, since we don't actually send the image data back from DRT to NRWT when the image hashes match. Does that make sense? Yep, you are right, I did some measures with rebased test resuts. The patch was also for ref-tests. There, we generate 2 PNGs in any case, correct or not.
Dirk Pranke
Comment 7 2013-01-29 13:53:59 PST
right, reftests will still be a problem (at least for the initial test, we should hopefully still be able to skip dumping the second png).
Note You need to log in before you can comment on or make changes to this bug.