- 主题:这个std::move(shared_ptr<Test>)能提高多少效率？
你可以比较有、没有的汇编代码
--
FROM 114.245.195.*
那学C/C++只是学了个皮毛啊，哈哈
【 在 DoorWay 的大作中提到: 】
: 这个目前坚决不学。
--
FROM 114.245.195.*
这个关系不太对。学C++不一定需要学C。
学C/C++需要懂一点汇编，不然怎么跟自己、跟人解释哪些地方效率提高了
如果不是为了运行效率，还不如去学go、java、js、py。
学汇编需要懂更多一点计算机原理，倒不用学穿纸带。
【 在 DoorWay 的大作中提到: 】
: 学C++得会C；学C得懂汇编；学汇编得会穿纸带？学忽悠人的，别信。
: 能认真看完Effective Cpp并且都懂，就算靠谱了。
: 后面还有那么多书要读呢。
--
FROM 114.245.195.*
抠细节的时候。比如要回答你顶楼里的这个问题
【 在 DoorWay 的大作中提到: 】
: 我做过的性能优化，都是VTune ATime测一下，标出热点，改改。
: 要么是系统性的上个jmalloc，或者针对某类对象，分配对象池。
: 项目类型不同吧。没有抠到极致，都是Low hanging fruits.
: ...................
--
FROM 114.245.195.*
各种crypto库里大把汇编的优化啊
比如OpenSSL里那个perl脚本生成的MD5汇编代码，很久以前对比试过，比它C的实现大约快30%
当然，这个并不是我做的，只是选型对比。
你不用，不代表别人不用，STL库里很多都用&&改造过了。
这些基础设施（或者叫轮子），是能优化就优化。不搞基础设施的，随便玩吧，只要业务别垮就行，不行砸钱加机器好了。
之前版上我记得还有一个说call层次太深导致性能问题的。所以编译器还会提供不建立ebp栈帧的可选优化。
这两天我在看一个人写的代码，std::string全是传值。。。
这会影响业务速度吗？小字符串肯定不会。但是给人的印象是业余
【 在 DoorWay 的大作中提到: 】
: 所以来探探大家的经验，你实际项目中，做没做过性能优化，抠到汇编这个层次没？
: 要是你，你定这个move不？
--
修改:z16166 FROM 114.245.195.*
FROM 114.245.195.*
之前不会。看了一下讨论，还是不要move shared_ptr了，只有能保证线程安全时才move。
原则上只要是后续不再需要的对象，传给别的函数，或者赋值给别的对象，都用std::move。
一般我只对比较重/大的对象、没有源码的对象用std::move。这个shared_ptr我知道它里面没几个字段。
因为我如果没这个类的源码，不知道这个类/对象的copy ctor和move ctor的性能开销，只能做一般的假定：move ctor更轻巧一些，性能更好。
shared_ptr<>这个当然有源码，在VC里的实现，其move ctor是4条整型赋值语句，copy ctor是2条整型赋值语句，加一条较重的InterlockedIncrement。
template <class _Ty2>
void _Move_construct_from(_Ptr_base<_Ty2>&& _Right) noexcept {
// implement shared_ptr's (converting) move ctor and weak_ptr's move ctor
_Ptr = _Right._Ptr;
_Rep = _Right._Rep;
_Right._Ptr = nullptr;
_Right._Rep = nullptr;
}
template <class _Ty2>
void _Copy_construct_from(const shared_ptr<_Ty2>& _Other) noexcept {
// implement shared_ptr's (converting) copy ctor
_Other._Incref();
_Ptr = _Other._Ptr;
_Rep = _Other._Rep;
}
顶楼里Raymond Chen的那个例子，传参move走后还用到了被move走的对象，就算没有求值顺序问题，也最好不要move。
Rust里默认就是move，而且move走的了变量是不可能再让你使用的，已经帮广大码农提高了下限了，只要不乱调用clone。
【 在 DoorWay 的大作中提到: 】
: 你说的我都知道。
: 我问的就是，你，实际的你，写这段代码，加这个move不？
--
修改:z16166 FROM 114.245.195.*
FROM 114.245.195.*