On Tue, Sep 30, 2014 at 4:57 AM, Kristof Beyls <kristof.be...@arm.com> wrote: >> > >> > This is a considerably more interesting case (at least to me) than >> > hypothetical benefits -- if we retain MSVC 2012 support, we will also >> > require /bigobj support, have slower compile times for ASTMatcher >> > projects, and slower benchmarks for clang-tidy. This points to >> > concrete benefits to expediting switching away from MSVC 2012, which >> > is why I am pinging this thread again. >> >> I guess I'm a little surprised that /bigobj is such a compile-time hit, >> but haven't tried any benchmarking. Anyway, whatever works best for you. >> --paulr > > I'm not 100% sure, but my understanding is that the huge number of template > instantiations is the root cause of the compile-time hit. It's the same root > cause that requires /bigobj to be needed, as each template instantiation > seems to need its own section? Therefore, /bigobj in itself probably doesn't > incur a compile-time hit, but rather the huge number of template > instantiations > produced. > Aaron, did I understand correctly that moving to MSVC2013 would allow to > adapt the code so that no longer a huge number of templates need to be > instantiated?
That is correct -- MSVC 2013 supports the language feature needed for that patch. That's not to say there aren't other solutions to the problem which are portable across more compilers. ~Aaron _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
