From: "John Torjo" <john.lists@torjo.com>
Ok, I haven't timed "typical use"; the only tests I've done in this respect is running the unit tests, but much of the time involved in that may well be taken by the test framework, as it uses mpl::for_each to iterate in two dimensions, taking a list of traits, and a list of types to test for each trait, which generates thousands of tests.
The unit tests take a rather long time to compile on Intel C++ (typically several minutes), but shorter on on MSVC, or g++.
that's a bit of a turn-off for me. I'm getting more and more annoyied by the fact that every time something *really cool* is discovered, it hits the compiler-time barrier.
As I've said in posts to c.l.c++.m, maybe it's time for a new language...
Or compilers optimised for heavy template use. :) There might be ways of optimising compilation time, but it may be very compiler-specific (http://users.rcn.com/abrahams/instantiation_speed/index.html). I've done some benchmarks, using the unit tests. The results are given below. System specification ----------------------------- Pentium II 350 MHz 384 MB 100 MHz RAM operator_traits_test.cpp --------------------------------- Intel C++ 7.1 - No debug info, optimisations off ---------------------------------------------------------------- 21 traits, 925 tests - 5 min 46 traits, 1981 tests - 21 min MSVC 7.1 - No debug info, optimisations off ------------------------------------------------------------- 21 traits, 925 tests - 2 min 46 traits, 1981 tests - N/A - fatal error C1204: compiler limit : internal structure overflow g++ 3.2 - No debug info, optimisations off --------------------------------------------------------- 21 traits, 925 tests - 7 min 46 traits, 1981 tests - > 30 min (*) (*) This used a lot of memory, > 330 MB, apparently leading to virtual memory trashing, and dramatic drop in processor utilisation, so in the end I stopped the compilation. Note that, as mentioned above, much of the overhead may be due to the test setup - it builds a long instantiation stack with mpl::for_each in two dimensions, and as you can see, on Intel C++ (EDG), the time taken doesn't grow linearly with the number of tests, but rather quadratic, or something like it. The traits are rather simple in structure - there's no recursion in the library itself, although it might be in the mpl::and_<>, mpl::or_<> and mpl::not_<> components that are used, and/or use of the PP-lib. Before doing any optimisation, I think one should first determine if there _is_ a problem, by benchmarking a real-life program with and without concept checking. Regards, Terje