> > > > 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? Thanks, Kristof _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
