我没明白你的意思，但是我记得过月优化的作者去螺洲实习了，在工坊说螺洲正在研究过月优化的事

这个编译优化对性能影响不算大吧，都是些蚊子腿

我现在在玩一个50多年的档，太吾村160多号人，感觉过月好像比之前22号更新前快了很多，不知道为什么。 内存6800ddr5，cpu14600kf。

这能不让我的cpu烧到90℃嘛？天天温度墙已经把我气的卸载了

哪有发布程序用debug模式的，我佛了c#应该有带调试信息的Release模式。而且正常的发布程序应该对外发布Release对内用Debug才对。这公司的程序员都是啥水平啊

为了比较严格的测试开启优化到底能提升多少性能，我指挥 GPT 搭了一个测试框架，核心思想是不直接运行完整游戏，而是抽出过月世界演化核心函数 AdvanceMonth 并用固定的随机数种子（DataContext.Random 和 WeightBasedPathfinder._randomSource）在同一个存档上连续进行三次过月（因为 .NET 作为虚拟机语言，其优化部分 JIT 需要进行预热）来测试性能。对比的是原版的 GameData.dll 和我手动去除其中的关闭优化标记的版本。

经测试，开启优化在我使用的存档上有约20%的稳定过月性能提升：

然后我测试了另一个骚操作，由于 .NET 框架的兼容性很好，你可以不改一行源代码和编译出来的 IL 代码，直接用新版本虚拟机运行旧版本，由于新版本虚拟机通常引入新的优化，能够白嫖一些性能提升。于是我将原有的 .NET 8 换成 .NET 11 Preview 5，又得到了稳定的5%性能提升。最终综合使得过月性能提升了三分之一左右：

结论是，虽然螺舟的程序员显然意识到了涉及过月的关键代码 GameData.ActionPlanning.dll 必须开启优化，但主 Assembly GameData.dll 关闭优化仍然会明显地拖累过月性能

另外除了过月本身，后面的存档部分也比较慢，而且慢的原因是比较清楚的，使用单线程 zip 压缩算法压缩存档其实耗费了大量时间，就算改成了倾向于存档速度依旧比较慢。对于这一点我已经在创意工坊发布了多线程存档 Mod，在我这里测试能将存档时间从5到6秒缩短到不足1秒（第二次开启本Mod存档时生效，第一次会备份你原来的存档额外耗时），大家有兴趣的话可以备份自己的存档然后试一试

虽然看不懂，但还是帮顶我经常受到unity崩溃的困扰（很奇怪，用两台电脑玩，一台一天玩到晚都没问题，另一个就很容易在某个操作以后unity崩溃，全部一样的设置，就硬件不同）

不懂代码，但我70年的档在前几天更新后确实是更快了

啊哈哈，这里是过月优化mod的作者。这个问题其实比较复杂哈，通过反编译应该可以注意到，由于开发周期的问题，各批次dll使用的dotnet版本不同。而且有批次编译/交叉编译后再载入dll的行为存在所以对于主模块的release优化模式开和不开是需要长期验证的（有72900哈，这里不再详细展开）。像actionplanning这一类模块会在更新中频繁变动所以顶层没有启用release应该可以理解？（我C++做的比较多，若有误请指出）还有一个就是目前的代码结构不具备对L1/L2 cache的亲和性，L3的命中率取决于任务批次大小。因此多线程相关的优化实装需要不少时间

过月优化不重要，我可以刷会抖音