From: Vincent S. <sc...@sa...> - 2007-01-17 11:43:29
|
Andrea Aime wrote: > Vincent Schut ha scritto: > >> Hi Andrea, >> >> some comments inline... >> >> > > >> Possibly just because file system layout issues? >> With embedded overviews you are only handling one file, which if you are >> lucky is contiguous on disk. It could even be that your OS is smart >> enough to cache (parts of) that file in memory, if you have enough. With >> the pyramid you have many files, scattered over several folders. That >> alone creates some (much?) overhead. >> Then it might be possible that these files are scattered over your disc >> platters, which creates more overhead (note: this can also be the case >> with the large tiff, but probably chances are lower because the OS tries >> to keep data per file contiguous, but doesn't know that all your pyramid >> files belong together, so starts filling holes on your disk with these >> files). >> And because your OS doesn't know these files belong together, caching >> won't be of much use, and may even be counter-productive because files >> are being put into the cache that won't be read again, thus polluting >> the cache, instead of with the one big geotiff, where you always use the >> same file. >> > > All good considerations, but in fact removing a single gt2 image reader > plugin (see my other mail) fixed the problem. > Yes, saw that one directly after clicking 'send'. Good, because that's easier to fix than filesystem issues. > >> Other performance issues can be thought of, like 'is the pyramid index >> file cached, or is it being re-read in between reading the pyramid >> data?', but I'd guess file system organization might be your major >> bottleneck. Not much to be done about, either, I'm afraid, then >> defragmenting your disk and hoping the pyramid files end up next to each >> other. The issue with one file handler versus many imho will always be a >> pyramid trade-off. >> >> I tried pyramids once, but found them hard to create, and found geotiff >> with embedded overviews had good enough performance. So I never tried >> pyramids again, and reading your story I'll probably keep it that way... :) >> > > Yeah, at the moment they are too hard to create, I agree. Indeed, but as geotiff+overviews performance is comparable for not extremely large files, I have no reason to use pyramids. > Yet, > performance now is good, a bit faster than the image with overviews. > I'm doing other tests, since apparently 1.4GB image is not big enough > to show the difference. > I'm now extracting the whole bluemarble 500m to a tiled and jpeg > compresed tiff file, then we'll see :-) (the original ecw is 230MB...) > Hey, that's peanuts. Be a man, try mosaicing all SRTM data (I once did) ;-) But watch out for the tiff 2 or 4 Gb limit. You might need to write a bigtiff plugin :) Cheers, Vincent. > Cheers > Andrea > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Geoserver-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > |