author Gregory Szorc <>
Wed, 30 Sep 2015 11:33:04 -0700
changeset 265430 4a19c58da5928924ab276092de5e00fabcff28b8
parent 40458 1584ba8c1b86f9c4de5ccda5241cef36e80f042c
permissions -rw-r--r--
Bug 1208320 - Decrease compression level of test zip archives; r=glandium Compressing C++ unit tests is a long pole when writing test archives. Experimenting with various levels of compression revealed that compression level 9 was providing minimal space savings for significantly longer archiving times and greater CPU usage. Results of our experimentation of `make -sj8 package-tests` on OS X with various levels of compression are below. Note: these numbers were accidentally obtained without JS tests being archived. This skews the results a little but doesn't impact the analysis below. ARCHIVE SIZE WALL CPU (L=9) cppunittest 76,806,629 30.6s mochitest 61,276,928 9.4s reftest 31,204,396 11.0s ALL 228,146,761 31.2s 75.9s (L=8) cppunittest 76,851,593 24.1s mochitest 61,279,322 8.9s reftest 31,207,867 10.4s ALL 228,228,096 24.9s 64.7s (L=7) cppunittest 77,102,292 14.3s mochitest 61,305,147 8.2s reftest 31,260,359 9.4s ALL 228,717,803 15.0s 49.1s (L=6) cppunittest 77,321,408 11.5s mochitest 61,336,539 8.2s reftest 31,303,604 9.2s ALL 229,123,307 12.2s 44.7s (L=5) cppunittest 78,226,404 8.2s mochitest 61,483,804 7.6s reftest 31,509,349 8.8s ALL 230,725,600 9.6s 39.7s (L=4) cppunittest 79,733,669 6.3s mochitest 61,825,519 7.6s reftest 31,924,171 8.4s ALL 233,669,991 9.0s 36.4s (L=3) cppunittest 82,380,731 5.8s mochitest 62,554,431 7.1s reftest 32,696,415 8.1s ALL 239,180,168 8.9s 34.6s Levels lower than 3 resulted in larger archives with no decreae in wall time and marginal decrease in CPU time. As we can see, lowering the compression level reduces archiving time by >3x while only increasing total archive size by ~2.5 MB or ~1% for compression level 5. Total time hits a plateau around levels 4 and 5. After that, file size increases faster for little decrease in wall time. I suspect that we're hitting Python limits from having to process thousands of files: there's only so fast Python can do I/O and make function calls. I think choosing 4 or 5 for the new compression level are acceptable. I went with 5 because the wall time savings from 5 to 4 are marginal and the archive size does start to increase a bit faster at 4. That being said, 4 does consume 10% less CPU. I could easily just 4 as well. 5 is more conservative. We can always change to 4 after seeing results in the wild. The end result of this change is `make package-tests` is much faster: Before: 228,146,761 bytes; 31.2s wall; 75.9s CPU After: 230,725,600 bytes; 11.4s wall; 45.0s CPU Delta: +2,578,839 bytes; -19.8s wall; -30.9s CPU When you take the whole series into consideration: Before: 44.2s wall; 84.6s CPU After: 11.4s wall; 45.0s CPU Lowering CPU is impressive considering we switched from the C `zip` implementation to Python! Keep in mind we were at ~78s wall before e87b74b3db43 introduced concurrent archive generation! And we still haven't eliminated the staging of JS tests, which are several thousand files and a few dozen MB!

Please see the file toolkit/content/license.html for the copyright licensing
conditions attached to this codebase, including copies of the licenses

You are not granted rights or licenses to the trademarks of the
Mozilla Foundation or any party, including without limitation the
Firefox name or logo.

For more information, see: