- 主题:这个std::move(shared_ptr<Test>)能提高多少效率？
有时候很莫名其妙的性能问题
以前用过QT的QByteArray，某个函数默认参数是空的QByteArray
总觉得这玩意应该没啥开销才对，生成一个空的QByteArray而已
结果过了很久发现多线程下这个函数性能有点问题
研究了一下发现QT的QByteArray也要加锁计数，指向一个全局变量
有时候莫名其妙的引用计数设计，不经意之间挖了个坑
【 在 z16166 (Netguy) 的大作中提到: 】
: 各种crypto库里大把汇编的优化啊
: 比如OpenSSL里那个perl脚本生成的MD5汇编代码，很久以前对比试过，比它C的实现大约快30%
: 当然，这个并不是我做的，只是选型对比。
: ...................
--
FROM 111.197.236.182
显然自己写的，谁会想到生成一个空QByteArray也会加锁啊
【 在 DoorWay (DoorWay) 的大作中提到: 】
: “某个函数”是项目写的，还是Qt写的？
--
FROM 111.197.236.182
你不业余的话，解释解释为啥多线程才有性能问题啊？
这里传不传引用，不是多线程性能瓶颈，实际上也用了引用
extern double funcB(..., const QByteArray &path)
double funcA(..., const char *path)
{
...
if(path)
return funcB(..., QByteArray(path));
else
return funcB(..., QByteArray());
}
你能一眼看出来这代码在多线程下有潜在性能问题？
评论别人前，先想想自己是否理解别人的问题
不要指责参数不统一，不同人的模块，不同的要求
funcA只可能是char*，因为要管理数量100M起步的小string，还要快速序列化
funcB是另外的模块，对它来说QByteArray性能足够了
【 在 DoorWay (DoorWay) 的大作中提到: 】
: 我只是觉得，默认参数使用一个类很奇怪。更奇怪的是传值。
: 显然这是个入参，正常传 const T&吧。—— 你可能属于 z1666说的“业余”。
--
FROM 111.197.236.182
因为qt5做了改进，那时用的是qt4
https://code.woboq.org/kde/include/qt4/QtCore/qbytearray.h.html
inline QByteArray::QByteArray(): d(&shared_null) { d->ref.ref(); }
inline QByteArray::~QByteArray() { if (!d->ref.deref()) qFree(d); }
static Data shared_null;
计数器ref的ref()虽然是原子操作，但是高并发下全局shared_null效率很低
这就是QByteArray()多线程效率低的原因，都在访问shared_null的ref
反倒是QByteArray(const char*)多线程下效率还行，毕竟是不同的ref操作
【 在 DoorWay (DoorWay) 的大作中提到: 】
: 首先，我有50%的概率跟你写的一样；有50%的概率会定义空的ByteArray. 取决于开发时的进度压力，或者当时着重解决的问题.
: [code=c]
: const QByteArray fkEmpty; // 模拟常见的 static const Vec3& Vec::Zero();
: ...................
--
修改:jjfz FROM 111.197.236.182
FROM 111.197.236.182
改起来倒是简单，static QByteArray emptyStr;
主要是没想到这里会有多线程性能问题，一个空string而已，能有啥开销
之所以发现是碰巧一天心血来潮测试了性能，比预期的差
因为很久之前做过类似的实现，用的是别的接口，大致性能有数
然后就发现了qt4让人ft的实现
【 在 DoorWay (DoorWay) 的大作中提到: 】
: 那在Qt4的环境下，是怎么改这个效率点的？当初又怎么发现的呢。
--
FROM 111.197.236.182