symphony09

从设计角度来说，我觉得比较重要的有两点： - 尽量无锁化执行，把状态修改逻辑集中到一个协程执行，有必要的情况下创建只读副本。 - 参考零成本抽象的概念，把切面等高级功能从核心调度逻辑中分离出来，如果不使用这个功能，就不会有额外开销。 从编码角度来说，就是持续做性能分析，通过对象预先创建和对象池减少对象分配，协程复用等等。 从语言角度来说，ograph 基于协程调度，cgraph 基于自研线程池调度。 go 协程经过 go 开发团队多年打磨，在线程复用、减少切换，任务窃取机制上更加精细。据我所知，cgraph 应该还不能感知陷入 IO 阻塞的任务并作出针对性优化。 更重要的一点，ograph 有更好的自适应性。要达到极致性能，cgraph 通常需要根据任务并发数和CPU核数合理设置线程数量，这意味着一旦部署环境改变或任务改动，都会对性能造成影响。 这也导致在实际性能测试中，cgraph 在不同环境下性能表现差异很大。