clang编译吃多核性能吗
① 编译llvm和clang需要多大空间
：转自知乎 蓝色 我最近和Clang/LLVM打交道比较多，目前游离在LLVM IR和IBM WCode之间。对于学习Clang/LLVM来说，其实需要看你做什么，是研究C, C++, Objective-C在Clang的实现，抑或着是想利用Clang做AST层面的事情，还是说想要利用LLVM IR来做
② 综合来说，几大主流C++编译器(icc,gcc,clang,vc++等)究竟孰优孰劣
我曾编出各种C++ 11编译器的支持，并有C++ 14编译器支持一批。
实际使用
对VC编译的速度不断提高，内存占用已经从VC12开始明显提高，而最明显的是可变参数模板。还有内置的代码静态分析，在实际中很有用。32位保护模式下，ss寄存器存的是一个段选择子，选择子是一个数字，通过IDT(局部描述符表)或者GDT(全局描述符表)选择一个段描述符，描述符里面的信息包含该段的取值范围和大小。
vc14的静态分析不在每次载入一个ie（对，以前每分析一个.cpp，就载入一次ie！），速度快了相当多。
③ GCC/G++，ICC，Clang，MSVC，BCC等C/C++编译器有什么特长和不足
clang编译速度快，但是貌似编译结果运行相对会慢。功能更新一般也比较快。
g++编译速度比clang慢，编译结果运行貌似比clang快。功能更新稍慢。
vc这几年没编译过大工程，感觉上编译速度在clang和g++之间。以过去的经验g++和vc编译结果运行速度差不多。功能更新上就是一坨屎。但是在Windows上写点正经东西你可能不得不用它，相对的你也只能在Windows上用它。
icc很久没用过，过去印象编译速度很慢，运行速度最快但是感觉有点得不偿失。最大的问题是这东西要钱，前三个都是免费的。
bcc直接无视就好了。
④ Clang 比 GCC 编译器好在哪里
编译速度更快、编译产出更小、出错提示更友好。尤其是在比较极端的情况下。
两年多前曾经写过一个Scheme解释器，词法分析和语法解析部分大约2000行，用的是Boost.Spirit——一个重度依赖C++模版元编程的框架。当时拦姿孝用g++ 4.2编译的情况是：
1.编译速度极慢：完整编译一次需要20分钟
2.编译过程中内存消耗极大：单个g++实例内存峰值消耗超过1G
3.中间产出物极大：编译出的所有.o文件加在一起大约1~2G，debug链接产物超过200M
4.编译错误极其难以理解：编译错误经常长达几十K，基本不可读，最要命的是编译错误经常会长到被g++截断，看不到真正出错的位置，基本上只能靠裸看代码来调试
这里先不论我使用Spirit的方式是不是有问题，或者Spirit框架自身的问题。我当时因为实在忍受不了g++，转而尝试clang。当时用的是clang 2.8，刚刚可以完整编译Boost，效果让我很满意：
1.编译速度有显着提升，记得大约是g++的1/3或1/4
2.编译过程中的内存消耗差别好像不大
3.中间产出物及最终链接产物，记得也是g++的1/3或1/4
4.相较于g++，编译错误可读性有所飞跃，至少不会出现编译错误过长被截断的问题了
当时最大的缺点是clang编译出的可执行文件无法用gdb调试，需要用调试器的时候还得用g++再编译一遍。不过这个问题后来解决了，我不知道是clang支持了gdb还是gdb支持了clang。至少我当前在Ubuntu下用clang 3.0编译出的二进制文件已经可以顺利用gdb调试了册羡。
最后一点，其他同学也有讲到，就是Clang采用的简稿是BSD协议。这是苹果资助LLVM、FreeBSD淘汰GCC换用Clang的一个重要原因。
⑤ xcode在用clang编译cairo库的时候出现的error和warning
cairo-quartz-font.c:789:26: error: implicit declaration of function
'FMGetATSFontRefFromFont' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
ATSFontRef atsFont = FMGetATSFontRefFromFont (font_id);
^
cairo-quartz-font.c:790:24: warning: 'CGFontCreateWithPlatformFont' is
deprecated: first deprecated in OS X 10.6 [-Wdeprecated-declarations]
CGFontRef cgFont = CGFontCreateWithPlatformFont (&atsFont);
⑥ 如何加快xcode编译速度
1. 增加XCode执行的线程数
可以根据自己Mac的性能，更改线程数设置5：defaults write com.apple.Xcode 5
另外也有一个设置可以开启：defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES
XCode默认使用与CPU核数相同的线程来进行编译，但由于编译过程中的IO操作往往比CPU运算要多，因此适当的提升线程数可以在一定程度上加快编译速度。
2.将Debug Information Format改为DWARF
在工程对应Target的Build Settings中，找到Debug Information Format这一项，将Debug时的DWARF with dSYM file改为DWARF。
这一项设置的是是否将调试信息加入到可执行文件中，改为DWARF后，如果程序崩溃，将无法输出崩溃位置对应的函数堆栈，但由于Debug模式下可以在XCode中查看调试信息，所以改为DWARF影响并不大。这一项更改完之后，可以大幅提升编译速度。
比如在目前本人负责的项目中，由于依赖了多个Target，所以需要在每个Target的Debug Information Format设置为DWARF。顺便提一下，如果通过Cocoapod引入第三方则Debug Information Format默认就是设置为DWARF的。
SDWebImage通过Cocoapod``Debug Information Format的默认设置
注意：将Debug Information Format改为DWARF之后，会导致在Debug窗口无法查看相关类类型的成员变量的值。当需要查看这些值时，可以将Debug Information Format改回DWARF with dSYM file，clean（必须）之后重新编译即可。
3.将Build Active Architecture Only改为Yes
在工程对应Target的Build Settings中，找到Build Active Architecture Only这一项，将Debug时的NO改为Yes。
664334-fa1eb995c140ce0f.png
这一项设置的是是否仅编译当前架构的版本，如果为NO，会编译所有架构的版本。需要注意的是，此选项在Release模式下必须为NO`，否则发布的ipa在部分设备上将不能运行。这一项更改完之后，可以显着提高编译速度。
4.设计编译优化等级
不要再项目中或者静态库中使用-O4，因为这会让Clang链接Link Time Optimizations (LTO)使得编译更慢，通常使用-O3。
注意：在设置编译优化之后，XCode断点和调试信息会不正常，所以一般静态库或者其他Target这样设置。
4.资源整合
4.1 将常用的代码及文件打包成静态库
4.2 添加预编译文件，把常用的头文件放到预编译文件里面
4.3 能用@class就用@class