[geos-devel] Re: [geos-commits] r3046 - trunk/src/geom

[strk]

Alright, convinced.
Thanks for the review.
r3060 has them back unchecked, with checks moved at PHP level.

--strk;

On Mon, Jun 21, 2010 at 01:23:08PM +0200, Maxime van Noppen wrote:
> On 06/21/2010 11:22 AM, strk wrote:
> > Not really.
> > You're right about additional cost, but I dubt it'll really
> > be noticeable. Have some profiles ?
> 
> Not directly on geos but testing the same scenario against a trivial
> example (attached) gives these results on gcc 4.4.3 :
> 
> $ g++ -O0 -o bench bench.cc && ./bench
> elapsed: 00:00:24.000799
> elapsed: 00:00:27.809378
> diff: 00:00:03.808579
> added cost: 15.8686%
> 
> $ g++ -O2 -o bench bench.cc && ./bench
> elapsed: 00:00:13.456086
> elapsed: 00:00:14.927550
> diff: 00:00:01.471464
> added cost: 10.9353%
> 
> $ g++ -O3 -o bench bench.cc && ./bench
> elapsed: 00:00:01.757662
> elapsed: 00:00:02.050734
> diff: 00:00:00.293072
> added cost: 16.674%
> 
> 
> First 'elapsed' is an unsafe access, second is the same access protected
> by an if().
> 
> It is clearly noticeable in any optimization level.
> 
> > We could move the checks in higher level APIs and
> > leave internals alone. Note that the C-API says it'd return
> > 0 on exception. Isn't asking for an non-existant child 
> > an exceptional request ? Should the C-API functions check ?
> 
> It is indeed an exceptional request and this is why I find that paying
> the cost of this additional safety for exceptional cases is too much.
> These methods are typically used in loop-intensive contexts.
> 
> Furthermore, they add no safety when used in loops such as :
> 
>  for(std::size_t i = 0; i < geom->getNumGeometries(); ++i)
>   // ...geom->getGeometryN(i)...
> 
> Having a safe and slow API is fine, std::vector has one, but not having
> an unsafe bust fast API is bad for those who care about performance.
> These functions are quite fundamental and broadly used in geos, this is
> going to slow down everything a bit.
> 
> As I don't use the C-API I don't know if it should do the test or not.
> I'd say that there should also be two functions, unsafe & fast and safe
> & slow. By the way, a lot of C code has the 'unsafe & fast' behaviour.
> Typically the libc : str{len,cpy,...} functions will segfault if they
> are given invalid arguments (NULL pointers, ...). So a C developer
> should be used to functions that fail when given invalid arguments.
> 
> -- 
> Maxime


> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel

-- 

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html