[cfe-dev] Clang 3.5 Release Pre-Pre-Pre-Announcement

[Yaron Keren]

FWIW, I found that clang compiled with Visual C++ in Debug mode too slow,
for two reasons.
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.
Example code:

void _Orphan_range(pointer _First, pointer _Last) const
 { // orphan iterators within specified (inclusive) range
 _Lockit _Lock(_LOCK_DEBUG);
...

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.

Yaron



2014-06-04 3:18 GMT+03:00 Richard <legalize at xmission.com>:

>
> In article <CAB8jPhdBfyyoY5=
> Vrnd5P67CpR4xk2SWRXaO7Tx6m0cnJotdHw at mail.gmail.com>,
>     Hans Wennborg <hans at chromium.org> writes:
>
> > I think /MT is right for the prebuilt binaries.
>
> There are varying opinions on this.  If you link to the runtime
> statically for executables, then you don't have to figure out how to
> distribute the runtime.  (Although this can be as simple as
> distributing the runtime DLL in your install directory and possibly
> including an application manifest.)
>
> > For the libraries, I'm
> > not so sure. I'm not familiar with how libraries are usually shipped
> > on Windows.
>
> For open source projects on our team, we compile in 4 variants:
>
> - 32-bit debug
> - 32-bit release
> - 64-bit debug
> - 64-bit release
>
> We compile everything as static libraries.  Debug static libraries use
> the debug C++ runtime.  Release static libraries use the release C++
> runtime.  We use the dynamic C++ runtime throughout.
>
> When you compile boost, it can build all the variants and you end up
> with a bunch of libraries.
>
> > Maybe the right thing to do is to ship the toolchain and SDK as
> > different packages?
>
> I think this is a reasonable idea.
>
> I was trying to figure out how to do that in CMake and my CMake-fu
> isn't quite up to snuff yet, so I haven't been able to contribute a
> patch.
>
> > That would save on download time for those who
> > just want the toolchain, and we can figure out what the optimal build
> > settings are for the library separately.
>
> I'm not concerned about download time[*], but more concerned about making
> sure that a usable collection of headers and libraries are available
> to avoid making people spend >30mins on an 8-core machine to produce
> a 9 GB build tree just to be able to experiment with a refactoring
> tool.  The lower we can make the bar for participation, the more
> participation we can get and as a community start building the
> refactoring tools we want.
>
> [*] This concern may be reasonable, but it's not one I care about :-).
> --
> "The Direct3D Graphics Pipeline" free book <
> http://tinyurl.com/d3d-pipeline>
>      The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
>          The Terminals Wiki <http://terminals.classiccmp.org>
>   Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140604/b0aa05e3/attachment.html>