windows下调试代码，有符号表和没符号表在某些方面的开发，差别较大，尤其是和一些windows基础库或偏底层的相关性较大的部分。巨硬的符号表服务器访问比较慢，一般为了能够快速进入调试模式，都是提前下好符号表，下面是根据遍历本机所有exe、dll进行符号表匹配并下载的命令
symchk /r C:\Windows\System32\ /s srv*D:\sym*http://msdl.microsoft.com/download/symbols这样做只能加快本机调试的速度，对于其他环境上的dmp解析，远程调试可能用处不大，主要取决于系统中各类库的版本是否和本机的一致。
由于最近使用的ffmpeg及其相关的库太过于老旧，所以需要进行更新。
对于视频方面的编码主要用到h264，音频则用到mp3、aac、speex。
其中最为坑的，还是mp3和aac。因为mp3中的分支太多，为了简化问题，最后还是选用lamemp3作为编码器。在ffmpeg 3.0开始，ffmpeg就停止了aacplus的使用，改为使用fdk aac。并且ffmpeg还自带了一个aac编码器。
在编译过程中由于没有注意到这个问题，因此使用了内置编码器，导致he aac编码出来的数据缺少sbr段。因此需要外部加入fdk aac来完成。
1、lamemp3源代码
2、speex源代码
3、fdk_aac源代码
4、x264源代码
5、ffmpeg源代码
6、安装msys2极其相应的工具（如果在windows上编译）
7、vs2015（如果在windows上编译）
lamemp3编译步骤：
直接代开源代码下vc_solution目录，使用vs2015编译即可
speex编译步骤：
打开win32目录下的vs2008直接用vs2015编译即可
fdk_aac编译步骤：
fdk_aac编译比较坑，不能在msys2中编译，需要用nmake(vs工具链)直接编译就好……
x264编译步骤：
在msys2中直接编译即可
ffmpeg编译步骤：
1，将speex、mp3、aac中include的部分代码拷贝到ffmpeg根目录下
2，在将相应的lib文件拷贝到根目录下的某个文件，这里用3rdparty来代表目录
3，执行编译命令
./configure –prefix=/c/work/github/ffmpeg_src_3.2/out –toolchain=msvc –enable-libx264 –enable-libmp3lame –enable-libfdk-aac –enable-nonfree –enable-libspeex –enable-gpl –extra-cflags=-IC:\\work\\github\\ffmpeg_src_3.2 –enable-shared –extra-ldflags=-LIBPATH:C:\\work\\github\\ffmpeg_src_3.2\\3rdparty\\lib
4，执行make和 make install之后即可
在最近webrtc的几个版本里，我一直尝试在windows上搭建编译环境。因为用惯了vs 2010，并且vs 2010之后的版本存在一个xp runtime的问题，所以一直想在vs 2010上编译。但是用不行，一直报错。
最近在看c++11标准，对比vs 2010 、vs 2013、vs 2015之后发现确实在c++11的支持上，vs 2015会更全面一些，所以最终还是只能用vs 2015作为编译环境来使用。
最近一直在通过远程桌面的方式使用笔记本，突然发现matlab死活都打不开，出现如下错误
起初以为安装出问题，后来网上看了下才知道是远程桌面的锅。直接用基本登录，问题解决。
首先先看一下下面两段C++的代码
这两段代码唯一的区别在于条件区域的代码不同，一个是在外面先把end的游标获取到，一个是在for执行的过程中动态获取。如果实在想不明白，那就直接上汇编把。
实际上在《高效C++》中就提到过关于for条件区域代码每次哪一种写法性能好，哪一种写法性能差。由于end函数在这里的性能开销可以忽略不计，但如果不是调用end而是调用一个性能开销比较大的函数，那么这个for循环会很慢；在多线程模型中，如果for中的条件区域代码是线程间需要同步的，那么有可能这个条件区块代码的执行结果在每一次循环时都会发生变化。
对于这种代码级的优化，实际中最好少用或者不用，但并不是不带着优化的思维去写代码，而是在写的时候就要意识到这块代码可能会成性能瓶颈。
下面图分别简易说明三种较常用的任务处理线程模型。
先说说为什么会来比较这三种任务线程模型，主要还得来于Chromium和手头工作中实际运用的特定问题；这三种任务线程模型在Chromium base的message_loop中都有过实现，且均用在不同的模块中（尽管message_loop中有大部分代码和boost中很像，或者就说直接拷过来的）。不过还是有必要值得讨论下这三种任务线程模型的特点。
这种模型构造最为简单，除了循环线程外，一般由一个临界、一个事件、和一个可以存放任务的数组或者stl容器组成。
但只可以同一进程内使用，或者经过内存映射后的跨进程通讯（一般没人这么干）。
任何任务的投递均要经历：
1，获取临界
2，往任务池中投递任务
3，激活事件
循环线程一般流程：
1，获取临界
2，取出任务池中的任务/等待事件激活
3，处理任务
对于循环线程可能会产生态变迁位置：
1，获取临界（虽然临界是用户态对象，但有可能会导致线程挂起等） —> 用户态转内核态
2，等待事件 —> 用户态转内核态
3，事件被激活，线程准备恢复执行 —> 内核态转用户态
总结：简单，态切换较少，且可能存在较大的线程时间处于用户态。速度快
*对窗口消息了解不是很多，所以这里只说一下仅有的少量了解。
这种模型构造组成：窗口、消息循环线程、其他辅助（例如要传递一个大内存，可能会用到共享内存等）。
特点：了解windows消息机制就可以用，且可以方便的处理一些和windows消息有关的任务，利用窗口消息分发特点可以很容易的划分任务类型。跨进程。
任何任务的投递均要经历：
1，获取窗口真实句柄
2，投递消息给窗口
循环线程一般流程：
1，等消息
2，取消息
3，分发消息
对于循环线程可能会产生态变迁位置：
1，等消息 —> 用户态转内核态
2，取消息(可能会出现，因为消息队列是用共享内存实现的，不清楚要不要做加锁操作) -> 用户态转内核态
3，分发消息（可能，由于一些消息是默认windows消息，或者是消息钩子链上的消息，需要把消息丢回消息链上，让其他进程进行处理） —> 用户态转内核态
*对iocp了解不是很多，所以这里只说一下仅有的少量了解。
这种模型构造组成：iocp模型、循环线程、其他辅助。
特点：可以方便的处理io相关的任务，内核态会创建一定量的线程数与用户态对应，需要做多次软中断；可跨进程。
任何任务的投递均要经历：
1，获取完成端口真实句柄
2，投递完成端口事件
循环线程一般流程：
1，等事件
2，取事件
3，处理事件
对于iocp线程可能会产生态变迁位置（实际上不全，因为在内核态还需要进行一次APC级别的软中断，iocp这种模型的一个任务流转过程，中断很频繁。详情请参考深入理解windows）：
1，等事件 —> 用户态转内核态
2，取事件 -> 用户态转内核态
3，处理事件
由于手头有份代码，当初的作者可能为了简单或者什么原因，借鉴了boost的iocp模型，并形成一个单线程的底层驱动模型。
早在一年前，刚好要在这个模型上面添加一个及时性要求比较的功能时，发现任务处理的及时性不稳定。有时候任务处理很及时，有时候任务处理延时很重。每个任务的消耗都尽量保持在一个相对平均的水平。
在该模型中频繁堆叠较重的任务后，发现原来是该模型任务处理性能不稳定（被测电脑也是个性能较差的电脑）。后来将及时性任务从该框架中剥离出来以后，问题得到了较好的缓解。
最近在boost，刚好手里有代码，就做个简单的测试。简易代码在这
其中77s对应的图是release下iocp模型，空转1亿次的耗时
其中46s对应的图是release下简单线程模型，空转1亿次的耗时
可见如果只是比较简易线程和iocp模型的话，简易线程的性能会比iocp快不少，但由于特定使用情况，也不能过分的教条。
好像从vs2010开始，vs自带的max宏就不再被推荐为C++中使用的首选，而是尽可能的改为std::max这个模板函数。
在effective c++中也讲到了max宏和std::max之间的差别（但有时使用起来，还是不如max宏来的方便，尤其是当max的入参不是同一个类型时。）
好了，说正事。
在vs2010中，std::max被定义为一个模板函数，其中函数的参数类型推导主要依赖于第一个参数；且std::max被inline修饰。在vs中，inline的强度并没有forceinline那么强，因此编译时，编译器即可能会让模板函数展开，也有可能不会让模板函数展开。
有时候有些开源项目中，大量的使用了std::max，这也会进一步的导致编译速度减慢，编译出来的文件变大；这里面除了inline还有一定的原因和模板的特性有关。
为了解决这类问题，有事不得不做出一些折中或妥协。即，当杜写一个公共函数，在该函数中将std::max进行特例化，以此来达到优化编译的目的。假设在不调整诸如fpo之类的优化参数时，编译器都会一定只会将std::max进行仅有的有限次实例化，且也可以控制函数是否进行inline。编译时不仅加快了编译速度，同时也减小了编译输出文件的大小。
所以在一些实际项目中，如果对编译产出的要求比较高，有时不得不牺牲代码设计和可阅读性来达到目的。
今天把工程全部转换成了vs 2013，主要是通过vs2013下的一些动静态代码检查功能。转换成vs 2013以后，发现编译器的检查更加严格了。一些警告会被视为异常，例如：
OSVERSIONINFO sInfo; sInfo.dwOSVersionInfoSize = sizeof(sInfo); GetVersionEx(&sInfo);
这段代码在vs 2013默认语法检查规则中是编译无法通过的。
查看msdn对GetVersionEx的说明(https://msdn.microsoft.com/zh-cn/library/ms724451(v=vs.85).aspx)
[GetVersionEx may be altered or unavailable for releases after Windows 8.1. Instead, use the Version Helper APIs]
该api由于不安全，在windows 8.1中会有一组函数进行对其替代。同时，对stl和编译预处理的检查将开始更为严格。后续需要对windows 8.1的api和之前windows的api进行差异性了解。通过可得知vs 2013的设计就是为了操作系统而准备的，有意或无意的改变程序员的部分编程习惯。
代码段如下：
#ifdef TEST_FLAG
#define MACRO_TEST_1(x) OutputDebugString(x)
#else
#define MACRO_TEST_1
#endif
static TCHAR g_all[] = _T("test_for_macro\r\n");
TCHAR* test_for_macro()
{
OutputDebugString(_T("call test_for_macro\r\n"));
return g_all;
}
当 TEST_FLAG 被定义和未被定义时，将会出现运行结果。
其实这个是一个老生常谈的问题，关于编译器在对宏的处理情况。
如果堆栈数据空间地址被恶意或无意的修改，导致执行了不该执行或数据段的二进制值指令叫做溢出攻击的话；这类宏的情况，在某些情形下也属于宏攻击。
首先从进程角度去看，内部其实是由一个或者若干个线程组成。因此在理解进程频繁创建和关闭导致的开销问题，只需要理解一个单一线程的频繁创建和关闭即可。
CreateThread、TerminateThread
这两个函数一个用于创建线程，另一个用于关闭线程。
1，先说一下线程创建的过程。对于CreateThread来说，创建的均为用户态线程。尽管创建的是用户态线程，但对于函数被调用者来说，本身还是需要切换到内核态或等待内核态服务线程将线程创建起来。
仅从这一点去看，有了态切换。显然就存在各种开销。
2，在内核创建好线程以后，这个线程将会被纳入windows的线程调度中，同时该线程所占有的内存资源也会被纳入内存调度中。仅从这里去看，又可以看到两个调度器的任务增加，且内存资源在减小。
3，在线程退出后，内核需要对其内存进行回收。在回收过程中，需要对线程的堆栈等系统分配给的内存资源进行校验（退出时的crash生成也在这一步）。检查完成以后，又要将回收回来的内存插回到windows的堆栈管理器里面（不管是crt堆，还是win32堆或者系统堆，都要插回去）。在回插内存的时候，可能还会引发堆内存的合并和子堆往父堆进行归还的过程。
通过以上描述，基本可得知线程的创建和关闭的开销是相当大的事情。
如果再深入一点看的话，可能会更清楚一些。
由于在windows系统以后，系统会“虚拟”出一个system进程，该进程内部其实是一堆辅助线程（有时候创建IO句柄时，也会出现这个进程里面的线程数增加，或者做调试的时候也有可能会出现类似的现象）。
system里面的线程，主要是用于服务在不同IRQL和内核用户态之间。换句话说，相当于一个桥（个人猜测，不负责哈！）。
当一个线程要进行关闭时，该system里面的辅助线程（15级以上），会对线程回收工作进行处理。换句话说，如果一个线程自己是正常退出的，那么自己会抛一个系统请求给system，让system把自己的内存回收掉。这个过程又要走一堆windows服务程序（服务端口），从这一点上看可得知。
一个线程的关闭，势必会激活一个“紧急”任务的进行，且会涉及到一个较长的流程。应此无论是创建还是关闭线程，如果执行频度太过于高，显然是不行的。
再看《深入理解windows》的时候，书中提到windows并非总是一个实时系统。主要原因是由于系统本身的设计，以及驱动，应用软件各方面一同构成的；然后就偶然了解到RTX这个辅助工具。
看了一下RTX的介绍，实际上RTX就是一个和windows内核相仿的一个系统。然后RTX会工作在一个或者几个独立的vcpu/cpu上，使得该vcpu/cpu变成一个实时系统。进而进行部分接管windows的一些中断响应、驱动操作。
然后就看到这个RTX的关于如何配置的视频时，听到对方介绍到用到RTX和没有用到RTX的系统。在用到了RTX的windows里面，对于一个1us采样的5s beep音频来说，能够流畅的播放出来。而对于一个没有使用RTX的是系统来说，就会出现断断续续的问题。
接着因为感兴趣对方是如何测试，就随手写了一段代码：
#include "stdafx.h"
#include <Windows.h>
int _tmain(int argc, _TCHAR* argv[])
{
for (int i =0; i<5000; ++i)
{
DWORD dwstart = GetTickCount();
Beep(750, 60);
DWORD dwend = GetTickCount();
printf("now cur %d, cost time %d\n", i, dwend - dwstart);
}
Sleep(1000*3600);
return 0;
}
由于gettickcount本身也是个严重不准的时间函数，所以也只能间接看一看；且整个声音均为断断续续。
通过测试发现，每个循环周期都有可能不是稳定的，有时候会存在2-5ms的误差，也或许和gettickcount的分辨率有关，或许确实和beep函数有关。
后来通过代码修改为如下，整个音频则变为流畅：
#include "stdafx.h"
#include <Windows.h>
int _tmain(int argc, _TCHAR* argv[])
{
Beep(750, 5000);
Sleep(1000*3600);
return 0;
}
通过上述观察然后跟踪了一下beep的汇编，汇编代码如下：
在msdn在NtDeviceIoControlFile中的描述：
参考beep函数的说明以后，在通过上述的描述；可见每调用一次beep始终是等待硬件处理完成以后，才会返回beep。然后又因为windows为非实时系统，所以就会出现上诉的代码1会出现发声会出现断断续续的问题。因为各种中断什么时候能够被处理，或者处理结束都是没有很强的约束性的。
当然，sleepex本身也是一个要走软中断的模块，显然也会影响到代码的发声情况。至于sleepex的精度情况，我自己没找到msdn官方说明，但参考waitforsingleobject和sleep，那sleepex精度也不会很高。
本来标题想取名成 《如何做好代码的性能优化》，但发现如果仅仅说代码性能优化的话就太狭义了。
最近一年一直在单线程框架的工程上写代码，阅读框架代码以后，不禁感叹道：“这个框架的设计者不仅是个高手，而且对windows相当了解，甚至借鉴了windows内核里面的一些设计元素。”
首先介绍一下我手里的这个框架：
1，总体来说，整个程序几乎就是单线程+异步（对于DNS解析、IO操作等一些耗时或难以异步的模块，会另启一个线程去执行和管理）。
2，在这个单线程框架中，所有的业务、网络协议栈、数据处理都在挂在这个单线程中去运行，并且绝大对数情况和业务下面都能够很好的运行。
3，模块间通讯采取模拟异步/同步事件、异步/同步消息的方式来完成
4，数据通讯很简单，直接用堆内存传递，用完立即释放。
5，定时器是最简单的“轮询”方式实现（并非真正轮询）
现在遇到一个比较严重的问题，就是在这个单线程模型中，由于开发的时候存在编码人技能层次不齐，以及任务力度控制不均匀。
导致开发一些功能在获得执行时间时，执行时间太长或没有及时的将任务中断并将执行时间让给其他任务执行。
这样的现象导致最严重的问题，自身流程过长，效率不一定高（如果还依赖其他模块的执行结果）。并且其他模块不能及时的拿到执行时间，并将执行结果及时反馈。进而引起血崩效应，导致部分要求时效性高的功能出现问题。
为了解决这类问题，就要做程序性能上的优化。这个问题上，一般采取的优化策略有几种：
1，代码级优化，就是通过各种技巧，将本来执行效率低的代码进行一点一点的修改并加快。这种优化方式周期长，效果不见得很明显，但对于长久来说是具备一定好处的；可以让优化者能够熟悉和了解整个代码的运行情况和流程等。
2，业务/功能优化，通过将长流程或者耗时的流程将功能和业务优化掉。然长流程变成短流程，然后进而增加执行时间在任务中的切换频率。可以促进轻量级任务的提早执行和结束，也间接能够提高大部分任务的及时性。但对于原本又长又臭的任务来说，此类优化可能带来的改善并不大，同时还需要优化者对程序整体有一定度的把握。
3，任务分拆，这样优化方式是将任务的关联性和时效性做一个定性分析。将相关任务集中起来，不相关任务分拆开；并将任务流中的上下游进行松耦，接着再对相关的业务进行松耦。这样做的好处在于一切以任务执行为视角，进行分拆，可以有效的区分开重任务和轻任务。同样也可以定性的了解到即使性要求高的任务和及时性要求低的任务。缺点在于，优化者同样也要对整个程序有一定的了解。
4，框架优化。这个难度大，没有做太大分析。
因为1和2都是夹杂着代码上技巧性的优化，这种优化如果考虑不当很有可能事倍功半，反而降低代码的可阅读性和可维护性。之前，我就遇到过一些成天嚷嚷着“算法”的人在用“算法”的思维去优化代码，结果代码优化下来性能是有一定的改善，但可维护性和可阅读性就差到极点了。甚至优化者本人自己去维度代码也是满天飞的bug。
介于4这种都是构架师水平，我最终选择3。
从任务的关联性出发，将一些重任务，以及及时性要求高的任务进行分类，并把这些任务的旁路任务进行一同整理。最终得到几类任务：
1，一般任务
2，及时性高任务
3，重任务
其中一般任务继续保留在原先的单线程框架中。及时性高的任务会从中剥离出来，并挂在一个新的单线程框架中；后期随着这个单线程任务量的增加，最终线程会逐步调整代码中的线程数。
重任务，其中重任务也被挂在一个新的单线程框架中，处理方式与及时性任务的处理方式一致。只不过对于及时性高的任务，可能还需要做一些代码层面上的执行优化，不过应该不多。
通过上面的方案进行优化了以后，发现整个客户端任务执行的拖沓、任务切换的不及时得到了较大的改善。看来改善任务安排有时候比起用一些代码技巧更为重要。
当然，我在这里说说是很容易的，实际写起代码来未必那么容易。因为涉及到多线程，就需要留意任务的关联性。因为关联性的存在，就会出现线程资源竞争，资源出现竞争时，就会很容易出现数据不同步，死锁，野指针等问题。
这是就需要经验和一定的代码技巧来解决这类问题。因此合理调整程序结构与代码技巧同样重要，如果一味的追求代码技巧和所谓的“算法”，那最终会失去对整个程序的可持续维护和开发的可能。这就如我之前所呆的一家公司一样，软件在国内某行业里还是有点小名气，但是真的要去看代码的话…………………bug、可阅读性不是在人类可理解范围内。反而这个团队内总有人一味的强调“算法”、“二叉树”什么的，数据结构与算法确实是程序的核心之一的东西，但现在国内的公司并非科研机构，顶多只能算一个做的工程。多数时候其实以工程的思维就能把问题解决好的，根本没有必要上升到“算法”层面，再说了，代码都没写好装什么逼呢？
了解了一下调试相关的内容，x86下的p6平台，大约支持的几种基本断点方式：
1，断点指令
2，向特定地址写数据
3，向特定地址读数据
4，操作特定IO地址（读写）
对于断点指令：int 3(0xcc)，当cpu执行到该指令时，会检查中断向量表，转为去执行中断服务“函数”
对于想特定指令写数据，同样也会检查中断向量表（实际上很可能不是中断向量表，因为引发的是一个寄存器检查，检查异常处理函数的地址），执行对应的代码块。
对于3，4与2的方式一样。
在VS里面，对于监控某个变量是否被修改成某个固定的值，很有可能是采用了上述的2或3这两个机制。当然，我这边的vs的反汇编代码其实只是指令上的判断而已，当修改成了我指定的条件时，最终会引发DebugBreak这个函数（这个函数最终还是执行int 3(0xcc)）
在VS里面还有没有发现那一种中断方式是对应着4的。
最近参与的一个项目中，由于重复的dump太多，为了简单处理问题。因此将dump放到同一个目录内进行集中解dump，下面是dump批量分析脚本
for %%i in (*.crash) do ( echo %%i my_windbg_a.lnk -y "SRV*D:\windbg_symbol*http://msdl.microsoft.com/download/symbols;E:\tmp\pdb" -z E:\tmp\crash1\%%i -WX -Q -logo E:\tmp\crash1\%%i.log -c "!analyze -v;q"
my_windbg_a.lnk是给windbg做的一个快捷方式
-y代表符号表位置
-z是 dump的位置
-Q代表退出的时候不显示对话框
-logo输出日志
-c发命令到windbg中
所谓的消息嵌套，说白了，就类似函数递归。下面存在这样一种场景，会导致所谓的嵌套发生。
需要解决一种使用场景，例如主线程post一个任务到MessageLoop的队列中，然后调用MessageLoop::Run。
这是进入消息处理，而这个抛入的任务实际上做的也是调用MessageLoop::Run。
那这就陷入了2个问题
1，要么出现多次“嵌套”，直到最后一个待处理的任务被执行完，然后再逐级返回，以至于最后一个任务被处理完。
2，要么直接死循环或者说是饿死。因为有可能抛入的任务都是调用同一个线程的MessageLoop::Run，然后最后被处理的任务被停在了事件等待上面，这个事件是用于等待有新MessageLoop任务抛入的。
因此nestable_tasks_allowed_ 标记就成了关键，这个标记控制着不允许任务会被嵌套的情况发生。