Preloading for dummies, continued
Yesterday, I posted about a stupid one-liner making quite some difference: 20% on x86-64 and 27% on x86. But I also mentioned, while writing about how disk seeks hurt, that the faster the disk, the bigger the difference. And the disk used on my test setup, with a sequential data transfer rate of 30MB/s, is quite slow by today's standards. So what about a faster disk (around 90MB/s) ?
| 4.0b8 | 4.0b8 with preload | Difference | |
|---|---|---|---|
| x86 | |||
| slow disk | 3,228.76 ± 0.57% | 2,347.18 ± 0.67% | 881.58 (27.30%) |
| faster disk | 2,926.14 ± 1.03% | 1,807.36 ± 0.99% | 1,118.78 (38.23%) |
| x86-64 | |||
| slow disk | 3,382.0 ± 0.51% | 2,709.82 ± 0.54% | 672.18 (19.86%) |
| faster disk | 3,211.86 ± 0.87% | 2,221.36 ± 0.57% | 990.5 (30.83%) |
2011-02-09 16:23:00+0900
You can leave a response, or trackback from your own site.
2011-02-09 18:02:25+0900
What happens if you make the cat asynchronous?
cat “$dist_bin”/*.so > /dev/null 2>&1 &
2011-02-09 18:12:31+0900
CaFxX: It’s (obviously) slower, because the firefox binary will require the data we want to preload before the cat ends, increasing the number of seeks.
2011-02-09 18:55:40+0900
Couldn’t it be that the firefox binary will require just some of the data, before the cat catches up and actually caches the data? In this way, the binary could start doing something _while_ the caching is in progress.
2011-02-09 19:36:48+0900
CaFxX: see the previous post, the firefox startup requires more than 80% of the libraries, and it does in a very non sequential manner.
2011-02-09 21:22:07+0900
I can help test on my Win7 machine. RAID0+1 (250MB/sec reads, 200MB/sec writes). =)
2011-02-10 00:10:13+0900
i have a dumb question: why don’t you use a lazy initialization? i mean in 99% of last visited websites, you don’t need webgl, svg, xslt etc.
2011-02-10 09:09:26+0900
Pete: because lazy initialization is not something the toolchain allows you to do without actually splitting things in separate libraries and dlopen()ing the unneeded part later. This is however something we’re going to try in the next months.