[gdal-dev] Bigtiff

[Helge Morkemo]

Hi all

I've been testing.
Seems like something happens when I set tilesize (BLOCKXSIZE/BLOCKYSIZE) to
256 or bigger.
My test program (VisualBasic2010) produced an untiled file of 100000x100000
pixels in 324 seconds. (Uncompressed, no overviews) I can live with that.

With tilesize 128 it takes 1586 seconds.
With tilesize 256 it takes forever (1.5 sec/ROW for the first 20)

Are there any caching options that I can set? Cache buffer size? Total cache
size? Other?
Will the performance be better if I write tiles instead of scanlines?

Best regards
Helge

On Thu, Jul 1, 2010 at 19:12, Axline, John <John.Axline at ngc.com> wrote:

>  It looks like  WriteRaster [or some other component in the process] hasused all available memory and now
> has to do massive amounts of churning between the last snippet of memory and
> your hard drive. Whether it’s a leak or a ‘feature’ of some library the
> author depended on is of course moot. If you can kill un-needed processes and
> free some memory (e.g. using Task Manager) you might get back into the 1
> pct/hour range, but probably would too-soon get back to glacial speed.
>
> If you don’t feel comfortable canceling tasks, you can lower their
> priority.  But don’t set your WriteRaster job (or anything) to realtime
> priority – in that situation your mouse/keyboard becomes so non-responsive
> the computer appears to be frozen.
>
> One or more unrelated processes (e.g. an automatic virus scanner) might
> also have become active, doing its chore inefficiently because of the lack
> of resources.
>
> You might also try the process on a 64-bit machine with a serious amount
> of memory, and a local high-speed disk  or (RAID 0) disk array.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100701/62268977/attachment-0001.html