实现哈希表之后的性能进一步优化

calcitem / chaosclock

C++ implementation of the "Chaos Clock" game invented by ejsoon, related information: https://quanquan.space/viewtopic.php?t=852

https://ejsoon.win/chaosclock/

1 stars 1 forks source link

实现哈希表之后的性能进一步优化 #23

Open calcitem opened 1 year ago

calcitem commented 1 year ago

V3 版本已经实现哈希表，解决了性能的大头，那么接下来优化什么呢？

基于 8a00c04481e2a983d7cd09691778c58a81999949 进行 VS 性能分析，发现几乎 100% 的耗时都在 pos->children.clear(); 这个函数上。

因此，如果将内存的分配和释放进一步减少，那么效率预计将还会大幅提升。

ejmoog commented 1 year ago

除了#22之外，還有一個，把board_map的uint64_t換成vector指針（注釋的那個，第72行）。

現在這個children.clear，把它注釋掉，看看是否結果仍相同？

因為每一個進到roll的都應該children是空的。

calcitem commented 1 year ago

VS 性能分析器可能出问题了，发现注释后，就跑到下一句

max_depth = max(depth, (int8_t)max_depth);

占用 100% 了。太奇怪了。

我将改换 gprof 跑一下看看。

calcitem commented 1 year ago

初步看来应该是和 VC 的 Debug 模式下卡在 getBoardMap 死循环有关。Release 模式正常。但是性能分析需要在 Debug 下运行。因此，我将再 Debug 看看是跑到哪里存在差异。一般 Debug 在申请内存后，不会清零，而是设置 0xbebebebebe 之类的固定魔数进去，可能会影响运行结果。

ejmoog commented 1 year ago

初步看来应该是和 VC 的 Debug 模式下卡在 getBoardMap 死循环有关。Release 模式正常。但是性能分析需要在 Debug 下运行。因此，我将再 Debug 看看是跑到哪里存在差异。一般 Debug 在申请内存后，不会清零，而是设置 0xbebebebebe 之类的固定魔数进去，可能会影响运行结果。

隨機數寫死後，現在還有死循環嗎？

calcitem commented 1 year ago

是的，原来是用 VC Release 模式，随机数写死就不死循环了，以为都 OK 了，不过现在切换到 Debug 模式就又死循环了，正在打印一些数据进行对比。

calcitem commented 1 year ago

已解决，原因和内存未初始化有关。https://github.com/calcitem/chaosclock/commit/ac8c9f604346b2f23d2af792a649afdff4ec94dc

稍后继续进行性能测试。

calcitem commented 1 year ago

如下为性能分析结果，百分比越高的，占用时间越多，就越是优化的大头。