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文件限制可适当加大，加快整体速度。