Philipp Reh wrote:
I'm using GIL's dynamic image extension, namely any_image_views in certain places. However on every occasion where an any_image_view is used I have to include apply_operation.hpp so the operations can be instantiated. On gcc-4.3.2 the inclusion of this header raises the compilation time at least tenfold. Somewhere on this list I found the claim that gil::variant is supposed to reduce compilation time over boost::variant but for at least gcc-4.3.2 this is untrue. There are several places in which I use boost::variant and even with binary visitation the compilation time is barely unnoticable.
Hi Philipp, Just to be clear, what makes the compile time increase is not the GIL variant header, nor the apply_operation.hpp header. It is all about the number of image types you are using and the algorithms you are invoking on any_image_view instances. If you use N images, each of your algorithms will be instantiated N times. Worse, if you use algorithms that take two any_image_view parameters, they will be instantiated N*N times! This is true for both GIL variant and boost::variant.
To work around this problem, I tried to explicitly instantiate the functions generated for my any_image_view. Trying this technique with apply_operation and detail::destructor_op failed. Looking at nm's output told me that what I explicitly instantiated and what the binary needs had at least its mpl::vector elements reversed.
So, I basically have two questions: 1) Wouldn't it be nicer to use boost::variant for gil, too? As far as I can see it does everything that is needed plus it compiles a lot faster (at least on gcc).
I would love to get rid of gil::variant and use boost::variant instead. The smaller GIL, the better. My earlier tests showed that compile times were better for gil::variant, but I did not test for every compiler, and it is possible that boost::variant has been updated since. If you strongly believe the problem is with gil::variant, it shouldn't be very hard for you to try replacing it with boost::variant and see if that improves things. We have created gil::variant to be fairly consistent with boost::variant.
2) Is it possible to explicitly instantiate the apply_operation function with the needed operations and if how so? If someone needs the code I tried and the error messages, I can post them.
Again, I don't believe the variant implementation is the core of the problem; the problem is that the variant technique is nice but has the potential of generating too many instantiations if you are not careful. We have developed a technique to share instantiations that are binary compatible. That should reduce the number of instantiations and the code bloat. On some compilers this also reduces the compile time, but there are cases where the compile time goes up due to the heavy-duty metaprogramming involved. This technique is working on an earlier version of GIL but has not been ported to the latest GIL. Lubomir