[GRASS-user] Re: new r.in.xyz Benchmarks

[Glynn Clements]

[CC'd to development list.]

Hamish wrote:

> > Good news with r.in.xyz. This program is really performing. I ran the
> > following tests:
> > 
> > Input file: 2006_Garry_Trough_1.txt
> > Size: 2.8GB
> > Time to Import: 8min, 24sec.
> > # of Points: 100,055,397
> > 
> > Input File: 2006_Garry_Trough_2.txt
> > Size: 3.2GB
> > Time to Import: 9min, 22sec.
> > # of Points: 115,947,033
> > 
> > Input File: 2006_Garry_Trough_3.txt
> > Size: 3.6GB
> > Time to Import: 10min, 33sec
> > # of Points: 126,162,261
> > 
> > This is really fantastic.
> 
> excellent. I'd still like to figure out a way to get LFS filesize
> (probably kb is best).  system("ls -s") isn't portable..

There isn't a truly portable solution. Some platforms might not even
have an integral type larger than 32 bits.

The most practicaly solution is to use ftello() if it's available.

This will require some configure checks. These are simple enough to
implement; it's the design which is problematic (as usual).

Unlike most HAVE_FOO checks, fseeko() isn't a simple have/don't-have
check. Rather, it's usually a case that the function is available only
when certain macros are defined (e.g. _LARGEFILE_SOURCE).

That gives rise to the question of what we check for, how we check for
it, how we pass that information to the code, and how we use it.

Rather than try to come up with some infrastructure which allows us to
use LFS in a piecemeal fashion, it would be preferable to clean up the
GRASS code so that we can enable LFS globally. Then, we can just add:

	-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64

to CPPFLAGS, and not have to worry about adding the necessary macros
to individual files. Any HAVE_* checks then become simple
have/don't-have checks.

-- 
Glynn Clements <glynn at gclements.plus.com>