<div dir="rtl"><div dir="ltr">FWIW, I found that clang compiled with Visual C++ in Debug mode too slow, for two reasons.</div><div dir="ltr">The first reason was that optimizations are turned off. The second one is trickier, if the libraries are Debug, Visual C++ defines _DEBUG which causes standard containers such as std::vector to perform extra work while the container is locked. In one case I profiled the Mutex by itself took 20% of the runtime. The container will lock even in single threaded programs.</div>
<div dir="ltr">Example code:<br></div><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><font face="courier new, monospace"><span class="" style="white-space:pre"> </span>void _Orphan_range(pointer _First, pointer _Last) const</font></div>
<div dir="ltr"><font face="courier new, monospace"><span class="" style="white-space:pre"> </span>{<span class="" style="white-space:pre"> </span>// orphan iterators within specified (inclusive) range</font></div><div dir="ltr">
<font face="courier new, monospace"><span class="" style="white-space:pre"> </span>_Lockit _Lock(_LOCK_DEBUG);</font></div><div><font face="courier new, monospace">...</font></div></div><div dir="ltr"><br></div><div dir="ltr">
I found Release with Debug Info mode + LLVM Assertions on to be a good compromise. When I need to debug into specific source files I turn optimization off.</div><div dir="ltr"><br></div><div dir="ltr">Yaron</div><div dir="ltr">
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div dir="ltr">2014-06-04 3:18 GMT+03:00 Richard <span dir="ltr"><<a href="mailto:legalize@xmission.com" target="_blank">legalize@xmission.com</a>></span>:</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
In article <CAB8jPhdBfyyoY5=<a href="mailto:Vrnd5P67CpR4xk2SWRXaO7Tx6m0cnJotdHw@mail.gmail.com">Vrnd5P67CpR4xk2SWRXaO7Tx6m0cnJotdHw@mail.gmail.com</a>>,<br>
<div class=""> Hans Wennborg <<a href="mailto:hans@chromium.org">hans@chromium.org</a>> writes:<br>
<br>
> I think /MT is right for the prebuilt binaries.<br>
<br>
</div>There are varying opinions on this. If you link to the runtime<br>
statically for executables, then you don't have to figure out how to<br>
distribute the runtime. (Although this can be as simple as<br>
distributing the runtime DLL in your install directory and possibly<br>
including an application manifest.)<br>
<div class=""><br>
> For the libraries, I'm<br>
> not so sure. I'm not familiar with how libraries are usually shipped<br>
> on Windows.<br>
<br>
</div>For open source projects on our team, we compile in 4 variants:<br>
<br>
- 32-bit debug<br>
- 32-bit release<br>
- 64-bit debug<br>
- 64-bit release<br>
<br>
We compile everything as static libraries. Debug static libraries use<br>
the debug C++ runtime. Release static libraries use the release C++<br>
runtime. We use the dynamic C++ runtime throughout.<br>
<br>
When you compile boost, it can build all the variants and you end up<br>
with a bunch of libraries.<br>
<div class=""><br>
> Maybe the right thing to do is to ship the toolchain and SDK as<br>
> different packages?<br>
<br>
</div>I think this is a reasonable idea.<br>
<br>
I was trying to figure out how to do that in CMake and my CMake-fu<br>
isn't quite up to snuff yet, so I haven't been able to contribute a<br>
patch.<br>
<div class=""><br>
> That would save on download time for those who<br>
> just want the toolchain, and we can figure out what the optimal build<br>
> settings are for the library separately.<br>
<br>
</div>I'm not concerned about download time[*], but more concerned about making<br>
sure that a usable collection of headers and libraries are available<br>
to avoid making people spend >30mins on an 8-core machine to produce<br>
a 9 GB build tree just to be able to experiment with a refactoring<br>
tool. The lower we can make the bar for participation, the more<br>
participation we can get and as a community start building the<br>
refactoring tools we want.<br>
<br>
[*] This concern may be reasonable, but it's not one I care about :-).<br>
<div class="im HOEnZb">--<br>
"The Direct3D Graphics Pipeline" free book <<a href="http://tinyurl.com/d3d-pipeline" target="_blank">http://tinyurl.com/d3d-pipeline</a>><br>
The Computer Graphics Museum <<a href="http://ComputerGraphicsMuseum.org" target="_blank">http://ComputerGraphicsMuseum.org</a>><br>
The Terminals Wiki <<a href="http://terminals.classiccmp.org" target="_blank">http://terminals.classiccmp.org</a>><br>
Legalize Adulthood! (my blog) <<a href="http://LegalizeAdulthood.wordpress.com" target="_blank">http://LegalizeAdulthood.wordpress.com</a>><br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>