[Geoserver-devel] GTOPO30 rendering slow

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.

Cheers
Andrea

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)

Here are some notes on the "magic numbers":

http://en.wikipedia.org/wiki/Magic_number_(programming)

Cheers
Andrea

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)

Here are some notes on the "magic numbers":

http://en.wikipedia.org/wiki/Magic_number_(programming)

Ho hum, here's a list of magic number detectors in java... interesting:

http://fredeaker.blogspot.com/2006/12/file-type-mime-detection.html

Cheers
Andrea

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)
      

Here are some notes on the "magic numbers":

Magic number (programming) - Wikipedia
    
Ho hum, here's a list of magic number detectors in java... interesting:

Shared Development: File type detection

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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  

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 :slight_smile:

Cheers
Andrea

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 :slight_smile:

Cheers
Andrea

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions

http://www.geo-solutions.it

-------------------------------------------------------