-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Tobias Schwinger Sent: Thursday, February 16, 2006 3:16 PM To: boost@lists.boost.org Subject: Re: [boost] Preprocessor: Nested loops
Paul Mensonides wrote:
Using macro expansion alone can be faster on some compilers
...such as?
The point is that file iteration is not *always* faster. The point at which file iteration becomes faster (typically) varies from preprocessor to preprocessor. E.g. #include <boost/preprocessor/arithmetic/inc.hpp> #include <boost/preprocessor/cat.hpp> #include <boost/preprocessor/repetition/repeat.hpp> #define M1(z, n, _) \ BOOST_PP_REPEAT(BOOST_PP_INC(n), M2, ~) \ /**/ #define M2(z, n, _) n BOOST_PP_REPEAT(100, M1, ~) Is often faster than the "equivalent" with file iteration. On gcc, for example, it is more than 10 times faster than if both inner and outer loops are done with file iteration. If the outer loop is done with file iteration, but the inner with REPEAT, it is slightly slower than just using macros. If the count is 200 instead of 100, than the outer file iteration + inner REPEAT is faster. And so on. It isn't simply that file-iteration is faster. What it ultimately comes down is how disabling contexts are implemented and how much effect they have on performance when there are a lot of them. The depth of file iteration, OTOH, doesn't make a significant difference (if it makes any). E.g. an inner iteration is just as fast as an outer iteration, but iteration itself carries its own overhead--it uses macros itself + lexical analysis and directive handling by the preprocessor. There is usually a point at which the complexity of active disabling contexts of macro expansion outweights the (comparatively high) constant factor of file iteration. Where that point is depends heavily on how a particular preprocessor's performance is affected by disabling contexts. So, macro expansion can be faster than file iteration, but file iteration is more consistently "fast enough" across compilers--because its overheads are relatively constant (i.e. not a function of "depth"). Regards, Paul Mensonides