[geos-devel] Assertions in CoordinateArraySequence

[Mateusz Loskot]

Charlie Savage wrote:
> 
>> Better idea is to provide two accessors: safe and unsafe, just as 
>> at() and operator[] member functions in std::vector.
> 
> Yes, this would be ok.
> 
>> IMO, no profiling is needed because this is well-known issue. 
>> Consider, why C++ Standard Committee introduced std::vector members
>>  I named above. Single if clause when called hundreds or thousands 
>> times will introduce significant overhead for sure. Exceptions are 
>> even worst, because RTTI comes to the game.
> 
> Um, well, it would be nice to see proof of this.  I have a hard time
>  imagining an if statement is going to make such a big difference.


Please, see exactly what I've written: hundreds/thousands and milions
of iterations.
Certainly, this cost may be not very observable in our case, but
there are situations it can make it bigger.

> Exceptions would of course be raised very rarely so that should have 
> no impact on performance.

Exceptions overhead does not only occur when exceptions are thrown.
The overhead lies in both execution speed and program size.
Exceptions introduce overhead also in many places:

- if there is a return instruction from the middle of try-catch block
then the system must throw a kind of silent exception to clean up the
stack what's very expansive.

- each try-catch blok forces compiler to push exception frame on the stack

- when exception is thrown, overhead can be caused by careless
programmer, e.g. if exception causes copy of heavy objects, calling
non-trivial constructor/destructor, this causes overhead too.

- RTTI support required by exceptions, also introduces some overhead.
Exceptions require some run-time information about structure of
functions, to determine if an exception was thrown from the try-catch
block or not.

>> IMHO, the most reasonable solution is to follow C++ STL design and 
>> take the same decisions to provide optimal performance with 
>> guaranteed degree of safety. So, all GEOS collections should 
>> provide similar API, doubled, save and unsafe at the same time like
>>  at() and operator[] in std::vector.
> 
> Yes, I'd be happy with that.  I think a scripting language should use
>  the "safe" version because its much more forgiving and if 
> performance is really such a big deal then you wouldn't be using Ruby
>  or Python - instead you'd write a C/C++ client against GEOS.

exceptions-enabled version (at()) is almost 2 times slower than unsafe
version - operator[].
Here is my small benchmark measured with callgrind:
http://mateusz.loskot.net/tmp/perf.png

Here you have much more professional benchmarks that proof the same:
http://groups.google.pl/group/misc.test/browse_frm/thread/19f69cead14a07e2/

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net