LiteSetup多线程优化方案

LiteSetup 轻量级安装程序框架  项目中：

主要是2方面能够多线程优化处理：UI和核心代码，核心代码的压缩多线程处理

1.最开始UI和核心代码在一个线程，致使可能假死现象，

解决方案：给核心代码单独开一个线程。

结果：解决假死问题。伪代码以下

...
void Compress()
{
std::thread t(...
{
...
});
t.detach();
}
...

 

2.因为核心代码跑在一个线程，致使只能利用一个CPU逻辑核心，压缩速度不快

测试数据：打包450MB 左右的ra2，可见 压缩占用时间20s ，io读写  分别为7s  和 0.2s

HDD数据

SSD数据

可见性能瓶颈在压缩处理

优化方案：

1.压缩部分开启多线程支持，在读取文件片断后即刻开启一个线程 来压缩 完成后添加到缓存队列，管理线程。

2.势必内存会疯长，因此限制当前文件缓存大小，例如： 若是缓存大小 大于100MB就马上写入。

3.若是压缩线程数为0，意味着压缩完毕，就马上把缓存的剩下部分，写入文件。处理后续事件。

整个过程以后压缩是多线程，文件写入是某个压缩线程完成后 执行的，文件读取是在核心线程完成。最后利用轮询是否平衡的

思想断定是否压缩完毕。

测试数据：（整个压缩过程（ 文件读取，数据压缩，文件写入））

优化前：   

整个打包过程 25s

优化后：

整个打包过程9s 

结果：加入多线程优化后，效率提高特别大，虽然线程开销致使等效时间（单独一个线程压缩时间，和多个线程每一个线程压缩时间之和）多了，36.912-23.461=13秒，可是总效率提高3倍。

部分核心代码：

进一步优化：虽然初步方案获得了很好的效果，可是线程效率比 不高，能够进一步优化。

1. 经过线程池来管理建立的线程，提升单个线程效率

2.dump文件（写入文件）的时候 添加多线程机制，原方案是在某个压缩线程中写入，可能会致使其余压缩完成但未写入缓存的线程挂起

3.调整不一样的文件块大小 ，可适当加大FileReader的文件块大小 减小线程切换代价，用内存换取时间。

4.dump文件限制可适当加大，加快总体速度。