- 主题:现代计算机存储空间增长很快，应该默认 inline
除非递归函数不能 inline, 不然大多数函数在编译的时候 inline 掉好像也不是啥坏事。
--
FROM 27.152.129.*
都inline 也不一定就好吧
都inline的话 binary大，iTLB iCache 如果miss那比call 开销要更大吧
【 在 hgoldfish 的大作中提到: 】
: 除非递归函数不能 inline, 不然大多数函数在编译的时候 inline 掉好像也不是啥坏事。
--
FROM 111.222.57.*
点赞。基础挺扎实的。
【 在 overcomeunic 的大作中提到: 】
: 都inline 也不一定就好吧
: 都inline的话 binary大，iTLB iCache 如果miss那比call 开销要更大吧
--
FROM 101.87.19.*
编译器现在已经很智能了，很多已经自动inline了吧
【 在 hgoldfish 的大作中提到: 】
: 除非递归函数不能 inline, 不然大多数函数在编译的时候 inline 掉好像也不是啥坏事。
--
FROM 183.199.185.*
【 在 overcomeunic 的大作中提到: 】
: 都inline 也不一定就好吧
: 都inline的话 binary大，iTLB iCache 如果miss那比call 开销要更大吧
re, 代码量过大, 影响代码缓存
--
FROM 61.48.14.*
怪不得现在微信那么大
【 在 hgoldfish 的大作中提到: 】
: 除非递归函数不能 inline, 不然大多数函数在编译的时候 inline 掉好像也不是啥坏事。
: --
: 灭绝人性啊
:
:
发自「今日水木 on iPhone SE」
--
FROM 183.194.160.*
活跃气氛
--
FROM 114.254.115.*
大佬再深入讲讲？
【 在 overcomeunic 的大作中提到: 】
: 都inline 也不一定就好吧
: 都inline的话 binary大，iTLB iCache 如果miss那比call 开销要更大吧
--
FROM 111.206.96.*
是不是得把binary放到生产跑一跑，看看能不能用PGO的信息再来指导一下编译器基于现场实际情况做相应的优化
内联，分支预测等等
【 在 baoge 的大作中提到: 】
: 大佬再深入讲讲？
--
FROM 106.11.31.*
原则上是不是高频使用的函数内联，低频使用的函数栈调用？
【 在 overcomeunic 的大作中提到: 】
: 都inline 也不一定就好吧
: 都inline的话 binary大，iTLB iCache 如果miss那比call 开销要更大吧
--
FROM 36.163.208.*