Hi Simone, hi all,
during my tests I found out that rendering GTopo30
files was quite slow. A quick profiling session showed
the vast majority of the time was spend in the
GrassAsciiGridRaster.parseHeader and in EsriAsciiGridReader.parseHeader,
both attempting to try and open the file thru the plugin system
when the grid coverage is created, due to a call to RenderedOp.getMinX()
This is something I have seen already in other places (getting the color
model for example): the rendered images apparently do not know what
format they should use, so they waste time trying to lookup the appropriate one.
Of course, one could optimize the parseHeader methods so that the SPI
"canDecodeInput" is faster (using some tricks used by the "file" command
in unix, that somehow guesses the mime type of files by using only
a few bytes at the beginning of the file), yet it seems to me
counter productive that a GTOPO30 reader starts a grid creation process
where the format has to be looked up again: it should force the use
of its own format.
Of course, one could optimize the parseHeader methods so that the SPI
"canDecodeInput" is faster (using some tricks used by the "file" command
in unix, that somehow guesses the mime type of files by using only
a few bytes at the beginning of the file)
Of course, one could optimize the parseHeader methods so that the SPI
"canDecodeInput" is faster (using some tricks used by the "file" command
in unix, that somehow guesses the mime type of files by using only
a few bytes at the beginning of the file)
By all means use whatever the fastest way is to figure out if you can process the file.
Jody
Andrea Aime ha scritto:
Andrea Aime ha scritto:
Hi Simone, hi all,
...
Of course, one could optimize the parseHeader methods so that the SPI
"canDecodeInput" is faster (using some tricks used by the "file" command
in unix, that somehow guesses the mime type of files by using only
a few bytes at the beginning of the file)
By all means use whatever the fastest way is to figure out if you can process the file.
Well, Simone fixed the issue, was a one line change in gtopo30 that makes a world of difference performance wise. He also optimized the
arc grid readers to perform smarter checks. Now it's as fast as the
disk and tile cache allows it to be, CPU is barely used when I
zoom and pan onto it. Cool
Hi list,
I would like to remark that I did not pay Andrea to write this email.
I tried at first but he was too expensive so the only solution was to
fix the problem.
Simone.
PS
Sorry for being stupid, I guess it is the consequence of my lack for
sleeping time lately.
On 1/23/07, Andrea Aime <aaime@anonymised.com> wrote:
Jody Garnett ha scritto:
> By all means use whatever the fastest way is to figure out if you can
> process the file.
Well, Simone fixed the issue, was a one line change in gtopo30 that
makes a world of difference performance wise. He also optimized the
arc grid readers to perform smarter checks. Now it's as fast as the
disk and tile cache allows it to be, CPU is barely used when I
zoom and pan onto it. Cool
Cheers
Andrea
--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions
