We will run two separate types of benchmarks on this flat panel data.
1. You would expect the second run at 0.5 pixel size to take 4 times the first run at 1 um pixel size. It only takes 2.4 times the first run indicating that there are other delays not related to rasterization.
2. You would expect the third run to take 15 times the first run since the TOP level has 15 instances of pannel3. It takes slightly more.
3. Increasing the raster buffer from 512MB to 1024MB improves the throughput a bit -- probably by reducing overhead associated with bands since there are 1/2 the number of bands to process.
Raster, Format and Compress
Dual 2.4 GHz Dual Xeon, gdsriplib v1.29, RHE3, threads = 4, DBS = 4 million
1. a second thread (create_tiff) waits for the raster thread to complete and then takes the raw bitmap, compresses it using packbits and writes the compressed file to disk. Once it completes its job, the raster thread can work on the next band (for the 1 buffer case ...)
2. If a second raster buffer is defined, the raster thread can start work on the next band while the create_tiff is doing its compression work. This can (and does in these examples) result in improved throughput.