"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:e82q57$4i4$1@sea.gmane.org... : "Ivan Vecerina" wrote ... : > I develop an internal application. For validation purposes, : > my preference so far has been to release "debug" builds : > (i.e. with all runtime checks enabled and without aggressive : > compiler optimizations). : > In this scenario, abstraction penalty can be huge, because : > inlining is weak/inexistent. : > : > Writing a "C-style" version of the basic algorithms I need : > (e.g. erosions etc), there is only a minor difference : > between debug and optimized builds (e.g. often less than x 2). : > Using generic GIL code ... I suspect that the difference : > would be of an order of magnitude. : : What is stopping you adding checks in an optimised version? Error 1 Command line error D8016 : '/O2' and '/RTC1' command-line options are incompatible cl This is about automatic range-checking and other runtime checks that can automatically be generated by Visual C++ into the generated code. They interfere with optimization, and inlining. Granted, I could either: - Work on finding a compromize between optimizations & tuning, and enabling library runtime checks. - Modify compiler options for specific code modules only ... but for now the software has been doing well without this, and the "full runtime checks" approach helps give an extra level of confidence when facing the regulatory guys. Over time, as our confidence level (experience with audits) increases, I might move towards more aggressive optimization [ in practice I have never had a problem detected in the field ] Anyway, the point is: In debug mode, abstraction penalty can be quite high. It can get even worse if your standard library implementation includes built-in runtime checks, as the one that ships with VS2005 (checked iterators can be excruciatingly expensive within an inner loop). And mixing runtime check options within the same target application does not work well (different in-memory representations...). It would help if compilers would already start by get better at inlining functions (especially single-statement functions) when generating code in debug mode. [ The same would apply when comparing boost::spirit to parsers based on code generators, such as flex ] -- Ivan http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form