tars C++源码分析
由于公司使用的taf框架是和开源的tars框架一脉相承,虽然经过几年的改造,几乎已经面目全非了,但是主体结构上相差不大
因此从tars框架的最初版本的源码分析上就可以理解整个核心链路了
本篇会分析开源的tars1.0版本和tars3.0版本,并探索3.0版本的优化原因,最后对他们的性能做一些比较
计划中还有一篇公司taf框架的分析,很有趣的是它的发展方向和tars3.0不太一致,因此可以对其性能和tars性能也做一番比较,遗憾的是出于保密需要,无法将其post在我的博客上了
tars编译问题
浅析跳表性能缺陷
由于redis和leveldb的兴起,跳表走入了大众的实现
相对红黑树而言,跳表非常容易理解,使其成为了红黑树的常见替代
刚好我在理解2-3-4树的时候写了红黑树,顺便写一个跳表来pk一下性能
结果是我万万没想到的:
在单线程下,跳表的性能几乎全方位被红黑树碾压
perf的使用
之前写过一篇c++ 分析 gperftools 总结
对普通的性能优化来说,gperftools已经足够了
但是如果要深入优化,还是需要借助linux内置的perf工具
这个工具的功能包括但不限于:
- 协助优化代码中的cpu热点
- gpertools最多只能精确到某一行热点,perf是汇编级别的,因此可以协助优化生成的汇编代码
- 协助优化代码的分支预测命中率
- 协助优化代码的cpu高速缓存命中率
- 协助优化代码中对内核部分的使用
- 协助理解代码运行时在linux的调度情况
hook的妙用
hook是一个非常有用的黑魔法
协程基于它的最大应用之一
我总结了一下hook的原理,和我遇到的hook场景
hook原理
我第一次看到hook这个词是在破解论坛上,大致意思是将指定函数替换成自己的,然后再去执行这个指定函数
批量pop堆以解决类定时器逻辑
最近遇到一个类定时器逻辑需求
可以抽象为write和rangeRead两个接口
- write
- 超高频,多线程调用
- 基本按从小到大写入(不严格自增)
- 基本不重复
- rangeRead
- 低频,固定一个线程调用
- 传入一个key,从最小值到key的所有值批量读取出来并删除
初步筛选方案
多线程方面
Blog添加2d模型
最初从jekyll迁到hexo的最大动力,就是hexo的live-2d插件的看板娘功能
相关攻略很多,例如Hexo-Live2d安装教程(自定义Live2d),不在赘述
我这里要写的是比较小众的spine模型在web上的展示
spine模型转图片
我兴冲冲的配好了hexo的配置和live-2d插件
Blog从jekyll迁移到hexo
Blog已经是第三次换框架了
最早是裸写html,然后迁到github pages的jekyll,目前打算换hexo了
由于github pages的jekyll不支持各种插件,因此非常难用