#2838 closed defect (fixed)
GTiffRasterBand::IReadBlock() is terrible slow for big number of bands and pixel interleaving
| Reported by: | Even Rouault | Owned by: | Even Rouault |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.6.1 |
| Component: | default | Version: | unspecified |
| Severity: | normal | Keywords: | |
| Cc: | warmerdam |
Description
This is due to the active preloading of other bands in case of pixel interleaving that is not protected against re-entrance. The consequence is that the depth of calls is proportionnal to the number of bands, and the global time quadratic in the number of bands !
Change History (2)
comment:1 by , 15 years ago
| Milestone: | → 1.6.1 |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:2 by , 15 years ago
In r16300: avoid precaching other bands if block cache size is not big enough to accomodate them
But pixel interleaving with huge number of bands sounds like a crazy idea...
Note:
See TracTickets
for help on using tickets.
Fixed in trunk (r16297) and in branches/1.6 (r16298). Tests added for both band and pixel interleaving in r16299