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 _______________________________________________ geos-devel mailing list geos-devel@geos.refractions.net http://geos.refractions.net/mailman/listinfo/geos-devel
