97
edits
Necko/MobileCache/MicroBenchmarks: Difference between revisions
Jump to navigation
Jump to search
Necko/MobileCache/MicroBenchmarks (view source)
Revision as of 14:37, 6 October 2011
, 6 October 2011→Sample results
| Line 144: | Line 144: | ||
The Nexus S seems to perform very well compared to the server, in fact it is generally faster! Note that the Nexus handles entries of size up to 8K pretty much as as fast as 128byte entries, whereas the Linux box maintains this performance only up to 4K. Note also the very first column in the Nexus-plot - most likely there is one outlier in this dataset. Let's study it closer and use "plot-telemetry.gnu" with the "telemetry-128.dat" file | The Nexus S seems to perform very well compared to the server, in fact it is generally faster! Note that the Nexus handles entries of size up to 8K pretty much as as fast as 128byte entries, whereas the Linux box maintains this performance only up to 4K. Note also the very first column in the Nexus-plot - most likely there is one outlier in this dataset. Let's study it closer and use "plot-telemetry.gnu" with the "telemetry-128.dat" file | ||
[[File:Nexuss-100iter-128byte-telemetry-nocache.png]] | [[File:Nexuss-100iter-128byte-telemetry-nocache.png|600px]] | ||
Observe that the first load takes a long time, caused by a delay between creating the channel to asyncOpen is called. I'm not entirely sure what can cause this, but I assume it's because it's the first load and certain things may have to be loaded and set up. It is not (should not be!) caused by the cache-service creating the disk-cache because caching is disabled in this test. It is easy to modify the test to load a couple of resources prior to starting the timed loop. | Observe that the first load takes a long time, caused by a delay between creating the channel to asyncOpen is called. I'm not entirely sure what can cause this, but I assume it's because it's the first load and certain things may have to be loaded and set up. It is not (should not be!) caused by the cache-service creating the disk-cache because caching is disabled in this test. It is easy to modify the test to load a couple of resources prior to starting the timed loop. The corresponding telemetry-plot from the Linux server looks like this | ||
[[File:Watson-100iter-128byte-telemetry-nocache.png|600px]] | |||
=== test_timing_cache.js '''(Obsolete)''' === | === test_timing_cache.js '''(Obsolete)''' === | ||