在服务性能优化的时候，第一步就是定位瓶颈出现在哪里，然后进行针对性的优化。对于非线上的服务，可以perf + 压测，找到相应的热点；对于线上服务，不太方便在生产环境挂上perf或者其他性能排查工具。一般都是预埋log，对可能的热点函数或者大循环的函数的执行时间进行日志监控。
1. 使用cpu周期作为记录时间的基准
Linux提供的API—gettimeofday()可以获取微秒级的精度。但是，首先它不能提供纳秒级精度，其次，他是一个库函数（可能不是系统调用），自身就有一定的开销，当我需要纳秒级精度时，误差会很大。
而且，测定函数的性能以时钟周期为单位比纳秒更加合理。当不同型号的CPU的频率不同时，运行时间可能差很多，但是时钟周期应该差不了多少（如果指令集一样的话）。
那么怎么测定时钟周期呢？x86处理器为我们提供了rdtsc指令。从pentium开始，很多x86处理器都引入了TSC(Time Stamp Counter)，一个64位的寄存器，每个CPU时钟周期其值加一。它记录了CPU从上电开始总共经历的时钟周期数。一个2.5GHz的CPU如果全速运行的话，那么其TSC就会在一秒内增加2,500,000,000。 （1GHz = 10^9 Hz）
rdtsc指令把TSC的低32位存放在EAX寄存器中，把TSC的高32位存放在EDX寄存器中。该指令可以在用户态执行。可以使用GCC内嵌汇编实现在用户态获取时钟周期：
uint64_t current_cycles()
{
uint32_t low, high;
asm volatile("rdtsc" : "=a"(low), "=d"(high));
return ((uint64_t)low) | ((uint64_t)high << 32);
}
int main()
{
uint64_t tick,tick1,time;
tick = current_cycles();
sleep(1);
tick1 = current_cycles();
time = (unsigned)((tick1-tick));
printf("\ntime in %lu\n",time);
return 0;
}
$ lscpu
Architecture: x86_64
CPU MHz: 2494.140
$ ./a.out
time in 2494289636 // 1秒钟 在2.4Ghz的cpu上面，1秒钟会产生24亿tick数
可以简单的对比一下，使用rdtsc获得时间会比gettimeofday的方式开销小的多，我就不在这里列举了。
2. 利用guard机制统计函数的执行时间
利用创建对象的生命周期去统计函数的执行时间
class CYCLE_PROFILER
{
public:
CYCLE_PROFILER(int id):_id(id)
{
rdtscll(_tsc_begin);
}
~CYCLE_PROFILER()
{
rdtscll(_tsc_end);
unsigned long int time = _tsc_end - _tsc_begin;
printf("func id : %s, begin %lu, end %lu, use cpu tsc %lu \n"
, stat_type_str[_id], _tsc_begin, _tsc_end, time);
}
private:
int _id;
unsigned long int _tsc_begin;
unsigned long int _tsc_end;
};
int test_func()
{
CYCLE_PROFILER guard;
// do-something
return 0;
}
3. 将每次函数执行的时间进行收集和汇总，周期性的输出统计的相应函数执行的时间。对于被统计函数，执行插入一行宏就可以。
int test_func()
{
CYCLE_PROFILER((int)_type_test_func);
int times = 1000000;
while (times > 0)
{
int value = times * times;
times--;
};
return 0;
}
简单的包装了一下：
https://github.com/zhaozhengcoder/CoderNoteBook/tree/master/example_code/perd_record
4. 一种获得函数调用时间的全链路追踪方案
在gcc和g++编译的时候，可以开启一个选择finstrument-functions编译选项，这样对每个函数在进入和离开的时候，会触发一个系统的回调。
__cyg_profile_func_enter(void *callee, void *caller);
__cyg_profile_func_exit(void *callee, void *caller);
那原理就很简单了，在每个函数进入的时候，插入一段逻辑，获得程序在这个函数中的执行时间和caller。
#define DUMP(func, call) \
printf("%s: func = %p, called by = %p\n", __FUNCTION__, func, call)
void __attribute__((no_instrument_function))
__cyg_profile_func_enter(void *this_func, void *call_site)
{
DUMP(this_func, call_site);
}
void __attribute__((no_instrument_function))
__cyg_profile_func_exit(void *this_func, void *call_site)
{
DUMP(this_func, call_site);
}
int do_multi(int a, int b)
{
return a * b;
}
int do_calc(int a, int b)
{
return do_multi(a, b);
}
int main()
{
int a = 4, b = 5;
printf("result: %d\n", do_calc(a, b));
return 0;
}
// gcc -finstrument-functions instrfunc.c -o instrfunc
./instrfunc
__cyg_profile_func_enter: func = 0x400693, called by = 0x7ffff7829555
__cyg_profile_func_enter: func = 0x400648, called by = 0x4006ca
__cyg_profile_func_enter: func = 0x400605, called by = 0x400677
__cyg_profile_func_exit: func = 0x400605, called by = 0x400677
__cyg_profile_func_exit: func = 0x400648, called by = 0x4006ca
result: 300
__cyg_profile_func_exit: func = 0x400693, called by = 0x7ffff7829555
gprof获得性能热点就类似于这种原理，给程序的所有入口函数插入代码。获得执行时间和调用堆栈。类似的，这个开源的日志追踪库也是这个原理：https://github.com/TomaszAugustyn/call-stack-logger。
5. rdtsc可能的问题
陈硕 —— 多核时代不宜再用 x86 的 RDTSC 指令测试指令周期和时间
https://blog.csdn.net/Solstice/article/details/5196544
- cpu的是频率是可以变化的，频率变化之后，tick是不准确的，要怎么办？
- 不同核心的tick是同步的么，如果不同步怎么办？
- cpu执行的指令有可能是乱序的，可能是测量的不准确
对于问题1，2，可以查看cpu是否支持const tsc。支持这个特性的cpu，它的tsc是按照其标称频率流逝的，与CPU的实际工作频率与状态无关。
问题3，除了 TSC 要准，还要顾及 CPU 的乱序执行，尤其是如果被测的代码段较小，乱序执行可能让你的测试变得完全没意义。解决这个一般是“先同步，后计时”，在 wikipedia 上的一段代码就用 cpuid 指令来同步 (http://en.wikipedia.org/wiki/Time_Stamp_Counter)。
