鸣潮的优化洗地艺术大赏

[檀越tanyue]

5. 对 Reddit 性能分析帖的回应

原文

A detailed performance analysis was posted to the WuWa community by @xLOCKnLOADx, based on hardware traces from a Snapdragon 8 Elite device (https://www.reddit.com/r/WutheringWaves/comments/1rtuzc8/wuthering_waves_performance_issues_analysis/). I want to be clear upfront: the data in that post is real and worth taking seriously. The measured numbers — 50% primitive rejection in open world, up to 99% in combat, L1 cache miss rates of 70–100%, FP32 shader dominance — come from actual hardware traces and should not be dismissed.

An important platform caveat: this section discusses mobile profiling data. Mobile and PC systems differ fundamentally — mobile uses tile-based rendering, unified memory, and aggressive thermal/power management, while PC uses discrete GPUs, higher bandwidth memory, and different rendering pipelines. Metrics such as primitive rejection rates, cache behavior, and GPU utilization do not translate directly between platforms. The causal arguments made here apply to the mobile context specifically; PC behavior should be evaluated separately using PC-native profiling. The coordination bottleneck argument for PC is supported by separate PC-native data presented in Section 1.2.

The issue is with the framing, not the data.

The post treats each GPU-side problem as an independent optimization failure: culling should be better, texture batching should be better, shaders should use lower precision. All of these are individually accurate observations. The conclusion — that none of them require a new engine — is also accurate.

What the post does not explain is why culling fails specifically under combat load.

The 99% trivial rejection rate in combat is not culling code that was written poorly. It is culling code that did not have time to run — because by the time the game reaches the GPU submission step, the GameThread has already consumed its entire frame budget on particle system updates, scripting ticks, and actor physics. There was no time left for culling.

Fixing the culling algorithm while the GameThread is still saturated does not fix the problem. It fixes a symptom. The cascade looks like this:

Root cause:   GameThread saturation  ←  engine architecture
        │
        ▼
Symptom 1:   CPU-side culling runs out of time before GPU submission deadline
        │
        ▼
Symptom 2:   Unculled geometry submitted → GPU performs trivial rejection
              (50% open world, up to 99% combat)
        │
        ▼
Symptom 3:   Draw calls jump across unrelated textures → L1/L2 cache thrashed
              (L1 miss 70–100%, L2 miss ~45%)
        │
        ▼
Symptom 4:   GPU stalls waiting for memory, then waits again next frame

Treating Symptoms 2–4 as independent failures misses that they share a root. The GPU isn’t doing wasted work because someone forgot to write culling code. The GPU is doing wasted work because the code that would have prevented it didn’t get scheduled.

A note on causal attribution: the cascade above represents the most architecturally consistent explanation for the observed data, but it cannot be verified without full profiler access to the codebase. There are at least three plausible hypotheses for the culling failure: (1) GameThread has no time budget left for culling — the engine architecture explanation; (2) the culling algorithm itself is poorly implemented — an implementation quality issue; (3) the culling pipeline is structurally misdesigned for this workload — a hybrid of both. The honest position is that engine constraints and implementation quality are two separate variables whose individual contributions cannot be separated from the outside. Both are present. Their relative weight is unknown. This analysis treats hypothesis (1) as the primary explanation because it is most consistent with the broader data pattern, but readers should weigh that accordingly.

One additional data point worth noting: community engine configs confirm that r.ParallelFrustumCull=1 and r.ParallelOcclusionCull=1 are functional in WuWa’s shipping build — suggesting culling work can be partially offloaded from the GameThread to parallel threads. Whether this meaningfully shifts the bottleneck profile in dense city areas would require profiling to confirm, but their availability indicates the culling pipeline is not entirely GameThread-serialized.

— Flagged by @HtooMyatLin3

The Android Scheduling Dimension

The mobile profiling post also misses a platform-specific amplifier that matters for understanding the mobile experience specifically.

On Android, the Energy-Aware Scheduling (EAS) system manages which physical CPU core each thread runs on, dynamically migrating threads between the “big” (high-performance) and “LITTLE” (efficiency) clusters based on recent load history.

The problem: EAS uses a historical weighted average to decide where to place a thread. If the GameThread has been light for a few frames — say, during a loading transition — EAS may judge it as a light workload and assign it to an efficiency core. Then the scene becomes dense. The GameThread spikes. But the OS scheduler doesn’t react instantaneously: it takes time to recognize the new load level and migrate the thread to the prime core.

During that migration window, the GameThread is doing heavy work on a core not designed for it. The culling budget collapses further. The cascade gets worse.

The Android AOSP documentation acknowledges this problem directly:

“Without the scheduler change to make foreground apps more likely to move to the big CPU cluster, foreground apps may have insufficient CPU capacity to render until the scheduler decided to load balance the thread to a big CPU core.”

Source: https://source.android.com/docs/core/tests/debug/jank_capacity

This dimension does not exist on PC — x86 desktop CPUs are symmetric. Mobile stutter has this additional amplification layer on top of the same GameThread problem. The symptoms look similar; the mechanics are different.

On FP32: The Cross-Platform Constraint

The profiling post suggests transitioning to FP16 shaders as a quick optimization for mobile Adreno GPUs, where FP16 throughput is genuinely 2× faster.

This is accurate for Adreno. It ignores that WuWa runs on Adreno, Mali, Apple GPU, desktop AMD, desktop Nvidia, and Intel integrated graphics simultaneously. FP16 behavior and gain vary significantly across these GPU families. Maintaining separate shader variants per GPU family means larger pak files (the community has a separate ongoing conversation about WuWa’s storage footprint) and QA burden that multiplies with every device class.

The tradeoff is real. It is not as simple as the post implies. Community member @HtooMyatLin3 adds an important hardware-level nuance: FP16 throughput on GTX-series hardware (e.g. GTX 1060) runs at 1:64 ratio vs FP32 — meaning FP16 would be catastrophically slower on that GPU family. Dropping FP16 support for GTX would be required before any meaningful shader precision optimization could ship. By contrast, AMD RX 570 has identical throughput on both FP32 and FP16, so the optimization gap is highly architecture-dependent rather than a simple “switch FP16 on” solution.

The One Genuinely Easy Fix

The post documented r.Streaming.PoolSize = 400 from the Perfetto trace. On flagship mobile devices with 12–16 GB RAM, reserving only 400 MB for texture streaming is directly why L1 and L2 caches get thrashed — textures aren’t loaded into faster memory ahead of time because the pool is too small to hold them.

This is a configuration value. It has no architectural tradeoff. It is the one finding from that analysis that is genuinely addressable without any of the complications I’ve described elsewhere.

On r.Streaming.FullyLoadUsedTextures and r.Streaming.HLODStrategy: These are real UE4 engine cvars — FullyLoadUsedTextures forces all active textures to stream in immediately, HLODStrategy 2 disables HLOD-specific streaming entirely. Community member @HtooMyatLin3 reports that both cvars were usable in older patches (visible in earlier AlteriaX config commits) but are now being set by Kuro via code or console at a higher priority level — confirmed through log analysis — meaning Engine.ini entries are overridden and no longer effective at runtime. This represents a case where an easy fix was available, was being used by the community, and has since been locked down in the shipping build.

机翻

Reddit 用户 @xLOCKnLOADx 基于骁龙 8 Elite 设备的硬件追踪，在《鸣潮》社区发布了一份详细的性能分析报告（https://www.reddit.com/r/WutheringWaves/comments/1rtuzc8/wuthering_waves_performance_issues_analysis/）。我想先明确：那篇帖子中的数据是真实的，值得认真对待。其中测量的数据——开放世界中 50% 的图元剔除率、战斗中高达 99% 的剔除率、L1 缓存缺失率 70–100%、FP32 着色器占主导——都来自真实的硬件追踪，不应被忽视。

一个重要的平台说明： 本节讨论的是移动端性能剖析数据。移动端和 PC 系统有根本性差异——移动端使用基于块（tile-based）的渲染、统一内存架构以及激进的功耗/散热管理，而 PC 使用独立 GPU、更高带宽的内存以及不同的渲染管线。诸如图元剔除率、缓存行为、GPU 利用率等指标不能直接在不同平台间套用。本文中的因果论证特指移动端上下文；PC 行为应使用 PC 原生性能剖析工具单独评估。关于 PC 端协调瓶颈的论证，则由第 1.2 节中独立的 PC 原生数据支持。

问题在于解读框架，而非数据。

该帖将每一个 GPU 端的问题视为独立的优化失败：剔除应该做得更好、纹理批处理应该做得更好、着色器应该使用更低精度。这些单独来看都是准确的观察。结论——它们都不需要一个新引擎——也是准确的。

但该帖没有解释的是：为什么剔除在战斗负载下会特别失效？

战斗中 99% 的微不足道的剔除率，并不是因为剔除代码写得差。而是因为剔除代码没有时间运行——因为当游戏到达 GPU 提交步骤时，GameThread 已经将其整个帧预算消耗在了粒子系统更新、脚本 tick 和 Actor 物理上。已经没有剩余时间留给剔除了。

在 GameThread 仍然饱和的情况下修复剔除算法，并不能解决问题。它修复的是一个症状。其级联关系如下：

text
根本原因： GameThread 饱和 ← 引擎架构
│
▼
症状 1： CPU 端剔除在 GPU 提交截止时间前耗尽了时间
│
▼
症状 2： 未经剔除的几何体被提交 → GPU 执行微不足道的剔除
（开放世界 50%，战斗中高达 99%）
│
▼
症状 3： 绘制调用在无关纹理间跳跃 → L1/L2 缓存被扰乱
（L1 缺失 70–100%，L2 缺失约 45%）
│
▼
症状 4： GPU 等待内存而停滞，下一帧再次等待
将症状 2–4 视为独立的失效，忽略了它们共享同一个根本原因。GPU 执行浪费的工作，不是因为有人忘记写剔除代码。GPU 执行浪费的工作，是因为本可以阻止这些工作的代码没有被调度执行。

关于因果归因的说明： 上述级联关系是针对观察数据在架构上最一致的解释，但如果没有对代码库的性能剖析器完全访问权限，就无法证实。对于剔除失效，至少存在三种合理的假设：(1) GameThread 没有剩余的时间预算用于剔除——引擎架构解释；(2) 剔除算法本身实现不佳——实现质量问题；(3) 剔除管线在结构上针对该工作负载设计不当——两者兼有。诚实的态度是：引擎约束与实现质量是两个独立的变量，从外部无法区分它们的各自贡献。两者都存在。它们的相对权重未知。本分析将假设 (1) 作为主要解释，因为它与更广泛的数据模式最为一致，但读者应据此自行权衡。

一个值得注意的额外数据点： 社区引擎配置证实，r.ParallelFrustumCull=1 和 r.ParallelOcclusionCull=1 在《鸣浪》的发布版本中是功能性的——这表明剔除工作可以部分从 GameThread 卸载到并行线程上。这是否能在密集城区中有意义地转移瓶颈，需要性能剖析才能确认，但这些 CVar 的存在表明剔除管线并非完全串行在 GameThread 上。

—— 感谢 @HtooMyatLin3 指出

Android 调度维度

该移动性能帖还遗漏了一个平台特定的放大因素，这对于理解移动端体验非常重要。

在 Android 上，能效感知调度（EAS） 系统管理每个线程运行在哪个物理 CPU 核心上，它会根据最近的历史负载将线程动态地在“大核”（高性能）和“小核”（能效）集群之间迁移。

问题在于：EAS 使用历史的加权平均值来决定将线程放在哪里。如果 GameThread 在过去几帧中负载较低——比如在加载过渡期间——EAS 可能会判定它为轻负载，并将其分配给能效核心。然后场景变得密集。GameThread 出现尖峰。但操作系统调度器不会立即做出反应：它需要时间来识别新的负载水平，并将线程迁移到主核心。

在这个迁移窗口期间，GameThread 在一个并非为其设计的核心上执行繁重工作。剔除预算进一步崩溃。级联效应变得更糟。

Android AOSP 文档直接承认了这个问题：

“如果没有将调度程序更改为使前台应用更有可能移到大核集群，前台应用可能在调度程序决定将线程负载均衡到大核 CPU 之前，就没有足够的 CPU 能力进行渲染。”

来源：https://source.android.com/docs/core/tests/debug/jank_capacity

这个维度在 PC 上不存在——x86 桌面 CPU 是对称的。移动端卡顿在相同的 GameThread 问题之上，还有这一层额外的放大因素。症状看起来相似，但机制不同。

关于 FP32：跨平台的约束

该性能帖建议转向 FP16 着色器，作为移动端 Adreno GPU 的快速优化方案，因为 FP16 的吞吐量确实是 2 倍。

这对于 Adreno 来说是准确的。但它忽略了《鸣潮》同时运行在 Adreno、Mali、Apple GPU、桌面 AMD、桌面 Nvidia 以及 Intel 集成显卡上。FP16 的行为和收益在这些 GPU 家族之间差异巨大。为每个 GPU 家族维护独立的着色器变体，意味着更大的 pak 文件（社区还同时在讨论《鸣潮》的存储占用问题），以及 QA 负担随设备类别成倍增加。

这种权衡是真实存在的。它并不像该帖暗示的那样简单。社区成员 @HtooMyatLin3 补充了一个重要的硬件级细微差别：在 GTX 系列硬件（例如 GTX 1060）上，FP16 吞吐量与 FP32 的比例为 1:64——这意味着在该 GPU 家族上，FP16 会灾难性地慢。在发布任何有意义的着色器精度优化之前，必须先放弃对 GTX 的 FP16 支持。相比之下，AMD RX 570 在 FP32 和 FP16 上具有相同的吞吐量，因此优化空间高度依赖于架构，而不是简单的“打开 FP16”解决方案。

一个真正简单的修复

该帖记录了 Perfetto 追踪中的 r.Streaming.PoolSize = 400。在配备 12–16 GB RAM 的旗舰移动设备上，仅为纹理流式加载预留 400 MB，这直接导致了 L1 和 L2 缓存被搅乱——纹理没有提前加载到更快的内存中，因为池子太小装不下它们。

这是一个配置值。它没有任何架构上的权衡。这是该分析中发现的一个真正无需我在其他地方描述的那些复杂情况即可解决的问题。

关于 r.Streaming.FullyLoadUsedTextures 和 r.Streaming.HLODStrategy：这两个是真正的 UE4 引擎 CVar——FullyLoadUsedTextures 强制所有活动纹理立即流式加载，HLODStrategy 2 完全禁用 HLOD 特定的流式加载。社区成员 @HtooMyatLin3 报告说，这两个 CVar 在旧版补丁中是可用的（在早期的 AlteriaX 配置提交中可见），但现在被 Kuro 通过代码或控制台以更高优先级设置了——通过日志分析得到确认——这意味着 Engine.ini 中的条目会被覆盖，且运行时不再生效。这代表了一个案例：一个简单的修复原本存在、被社区使用，但此后在发布版本中被锁定了。

[檀越tanyue]

6. 更艰难的真相

Kuro 实际所处的位置

原文

Kuro isn’t doing nothing. They’re also not in a position where they can optimize their way to smooth performance across all hardware tiers. What they’re in is something harder: a local optimal trap — a state where every available move makes something worse.

• If they pause content to do deep optimization work: player engagement drops, revenue drops, the project’s survival is threatened — which removes the budget and rationale for optimization
• If they keep shipping content without optimization work: technical debt compounds, performance degrades, player frustration grows
• If they attempt large architectural refactors: they risk catastrophic regressions in a live system that cannot tolerate them

Every direction has a cost. The current state isn’t laziness. It is the equilibrium that emerges when every alternative is worse.

The TS→C# migration is significant because it is not optimization within this trap — it is an attempt to change the shape of the trap itself. Local search — fixing individual culling issues, tuning shader precision — improves performance incrementally but cannot change the underlying constraints. The scripting migration is a structural change that opens solution space not accessible from the current position.

It will not fix the GameThread ceiling. UE4’s threading model will still limit how much work can be parallelized. But removing V8’s stop-the-world pauses from the frame budget gives the GameThread more headroom, and reduces the severity of the worst-case stutter events. That is a meaningful improvement even if it is not a complete solution.

机翻

Kuro 并非无所作为。但他们目前也无法通过优化让游戏在所有硬件层级上都获得流畅表现。他们所处的境地更加艰难：一个局部最优陷阱 —— 在这个状态下，任何可行的行动都会让某方面变得更糟。

• 如果他们暂停内容更新去做深度优化工作：玩家留存率下降、收入下降、项目的生存受到威胁 —— 这反过来会夺走优化的预算和理由。
• 如果他们继续推送内容而不做优化工作：技术债务持续累积、性能恶化、玩家的挫败感不断增长。
• 如果他们尝试大规模架构重构：则会在一个无法容忍严重倒退的在线系统中，冒着灾难性回归的风险。

每一条路都有代价。当前状态并非源于懒惰。这是一种均衡状态 —— 当所有其他选择都更糟糕时，自然形成的均衡。

TS → C# 迁移之所以意义重大，是因为它并非在这个陷阱内部 进行优化 —— 而是一次试图改变陷阱本身形状 的尝试。局部搜索 —— 修复单个剔除问题、调优着色器精度 —— 能逐步改善性能，但无法改变底层的约束条件。脚本迁移是一项结构性变更，它打开了从当前位置无法触及的解决方案空间。

它不会解决 GameThread 的天花板问题。UE4 的线程模型仍然会限制可并行化的工作量。但是，将 V8 的 stop-the-world 暂停从帧预算中移除，可以为 GameThread 提供更多的裕量，并降低最坏情况卡顿事件的严重程度。即使这不是一个完整的解决方案，这仍然是一项有意义的改进。

[檀越tanyue]

啊对对对这就是你在包体里同步运行两套石山导致包体大小爆炸和做不了优化的理由是吧

[檀越tanyue]

视觉野心：放大器，而非根本原因

原文

A common narrative in performance discussions goes like this: “Kuro is too ambitious with graphics — if they toned down the visuals, the game would run fine.”

The hardware data does not support this.

The test is simple: if visual ambition is the root cause of stutter, then disabling it should eliminate stutter. Community Engine.ini configs from AlteriaX allow players to disable RT, reduce shadow resolution, lower ViewDistanceScale, cull foliage density, and reduce crowd density to near-zero. Players using these configs report better FPS — but Pattern A stutter in Academy and Pattern B spikes during boundary transitions persist. Severity decreases. The pattern does not disappear.

This distinction matters: severity is affected by visual settings. Existence of the bottleneck is not.

Three benchmark videos illustrate the hardware scaling pattern across very different visual configurations:

i5-4690 + GTX 750Ti, lowest settings, FSR on (v3.0, pre-3.1 streaming fix): Walking in Academy: high 30s–45fps. Using vehicle or fast movement: drops to mid-20s–35fps. Fast vehicle on open-world roads: stable ~30fps. Combat with complex VFX: mid-20s–30fps. — Benchmark

This is a GPU from 2014 with 2GB VRAM, on lowest settings. The game is playable. The stutter pattern — stable while walking, drops during fast boundary crossing and vehicle use — is identical to what higher-end systems experience, just at a lower FPS floor.

i5-1035G1 + integrated graphics, 8GB RAM, 720p lowest settings (below minimum spec) — @Phantom_Tempest:

Overall performance: ~15fps. Notably, frame pacing remained relatively consistent compared to higher-end systems operating at higher frame rates. Thread utilization pattern unchanged — a small number of threads dictated performance, TaskGraph workers continued sawtooth burst behavior. Worker thread activity appeared more uniform than on higher-end hardware, with reduced burst amplitude — likely because reduced main-thread throughput feeds work to workers at a slower, more consistent rate rather than in large bursts.

Despite 8GB RAM operating under significant memory pressure (fully utilized), this did not appear to be the primary driver of frame pacing — it contributed to overall performance cost without fundamentally altering the execution pattern.

Note: This system operates below minimum spec, introducing additional variance from memory pressure, reduced GPU throughput, and lower sustained CPU performance. Absolute metrics are not directly comparable. The purpose is behavioral observation under constraint — and within that context, results remain consistent with higher-end observations.

The most significant insight from this data point: at ~15fps, the frame time budget is ~66ms per frame vs ~16ms at 60fps. The coordination bottleneck is still present — thread utilization confirms this — but its impact on perceived smoothness is less visible because the system is already operating so far below the threshold where stutter is perceptible. This is consistent with the observation from GTX 750Ti users: the bottleneck pattern exists at all hardware tiers, but severity scales with the gap between hardware capability and engine ceiling.

i7-4790K OC 4.7GHz + GTX 1660 Super, low-medium settings, FSR on (v3.1): Pre-vehicle traversal: ~55–60fps. Vehicle inside Academy: 30–45fps. Vehicle on open-world roads: high 40s–50s. Combat: 35–60fps depending on VFX complexity. 1% low in Academy: 8–15fps. — Benchmark

The 1% low of 8–15fps likely captures Pattern B-like compound spikes during fast transitions, alongside regular city frame pacing instability from Pattern A, streaming warmup, shader compilation, and VFX complexity. A 4790K OC’d to 4.7GHz is still hitting the coordination bottleneck because IPC, not clock speed, is the constraint.

i7-9700K + RTX 2080 Super, high settings, no RT, DLSS Quality (v3.1): 1080p — walking in Academy: stable ~60fps. Vehicle inside Academy: 45–60fps. Open-world vehicle: stable 60fps. Combat: 55–60fps. 1440p — walking in Academy: avg ~47fps, range 47–60fps. Vehicle inside Academy: drops to ~40–50fps. 4K — Academy pattern similar to 1440p. Fast open-world movement: high 40s fps. Combat: high 40s–50s fps. — Benchmark

Note: RT is OFF in this configuration. No visual ambition premium being paid for ray tracing — yet the bottleneck pattern persists at 1440p and 4K as resolution increases and GPU becomes a co-factor.

What this data shows together:

Across these three hardware tiers — spanning GTX 750Ti to RTX 2080 Super, lowest to high settings, 2GB VRAM to 8GB VRAM — the same pattern repeats: stable traversal, drops during fast movement and boundary crossing, combat VFX adds additional pressure. The bottleneck mechanism is present at all tiers.

Visual ambition does contribute real cost — RT increases RenderThread pressure, complex VFX competes for GameThread budget, higher resolution increases GPU frame time. When these costs combine with the GameThread coordination bottleneck, frame budget shrinks faster and the ceiling becomes visible sooner. This is what @Phantom_Tempest describes: “visual ambition amplifies existing constraints in the engine.”

But the constraints exist regardless. Disabling visual ambition reduces severity. It does not eliminate the architectural bottleneck. The correct framing is not “Kuro is too ambitious with graphics, that’s why the game lags” — it is that Kuro’s visual ambition makes an existing architectural problem more visible, more frequently, across more hardware tiers.

The GTX 750Ti data makes this concrete: a card that cannot run RT, cannot handle high settings, running at lowest crowd density — still exhibits the same stutter signature. The engine architecture is the floor. Visual settings determine how quickly you hit it.

机翻

性能讨论中一个常见的叙事是这样说的：“Kuro 对画质太激进了 —— 如果他们降低视觉效果，游戏就能流畅运行。”

硬件数据并不支持这一说法。

检验方法很简单：如果视觉野心是卡顿的根本原因，那么关闭它就应该能消除卡顿。AlteriaX 提供的社区 Engine.ini 配置允许玩家关闭光线追踪、降低阴影分辨率、调低 ViewDistanceScale、剔除植被密度、并将人群密度降至接近零。使用这些配置的玩家反馈帧率确实有提升 —— 但学院中的模式 A 卡顿和边界切换时的模式 B 尖峰仍然存在。严重程度下降了，但模式并没有消失。

这个区别很重要：视觉设置影响的是严重程度 ，而非瓶颈的存在本身 。

三组基准测试视频展示了在截然不同的视觉配置下，硬件性能缩放的模式：

• i5-4690 + GTX 750Ti，最低画质，FSR 开启（v3.0，3.1 流式修复之前） ：在学院中行走：35–45 fps。使用载具或快速移动：降至 20–35 fps。开放世界道路上快速载具：稳定约 30 fps。包含复杂 VFX 的战斗：20–30 fps。 —— 这是一块 2014 年的 2GB 显存 GPU，在最低画质下。游戏可玩。卡顿模式 —— 行走时稳定，快速跨越边界和使用载具时下降 —— 与更高端系统上经历的模式相同，只是帧数底线更低。
• i5-1035G1 + 核显，8GB 内存，720p 最低画质（低于最低规格）—— @Phantom_Tempest ：
  整体性能：约 15 fps。值得注意的是，与运行在更高帧率的高端系统相比，帧时间节奏相对更一致。线程利用模式未变 —— 少数组线程决定性能，TaskGraph 工作线程继续呈现锯齿状突发行为。工作线程活动比高端硬件上看起来更均匀，突发幅度减小 —— 很可能是因为主线程吞吐量降低，以更慢、更稳定的速率向工作线程喂养工作，而非以大的突发形式发生。
  尽管 8GB 内存处于显著的 memory pressure 下（完全占用），但这似乎并非帧时间节奏的主要驱动因素 —— 它增加了整体性能成本，但并未根本改变执行模式。
  注意：该系统运行在最低规格以下，引入了来自内存压力、降低的 GPU 吞吐量以及较低持续 CPU 性能的额外变量。绝对指标不可直接比较。其目的在于观察在约束下的行为 —— 而在此上下文中，结果仍然与更高端观察一致。
  该数据点最深刻的洞察：在约 15 fps 时，每帧的时间预算约为 66 毫秒，而在 60 fps 下约为 16 毫秒。协调瓶颈仍然存在 —— 线程利用率确认了这一点 —— 但其对感知流畅度的影响不太明显，因为系统已经远低于卡顿可感知的阈值。这与 GTX 750Ti 用户的观察一致：瓶颈模式在所有硬件层级上都存在，但严重程度随硬件能力与引擎天花板之间的差距而缩放。
• i7-4790K OC 4.7GHz + GTX 1660 Super，中低画质，FSR 开启（v3.1） ：使用载具前：约 55–60 fps。学院内载具：30–45 fps。开放世界道路上载具：45–50 fps。战斗：35–60 fps（取决于 VFX 复杂度）。学院中 1% 低帧：8–15 fps。 —— 该数据点中的 1% 低帧 8–15 fps 很可能捕获了快速切换时的模式 B 类复合尖峰，以及来自模式 A、流式加载预热、着色器编译和 VFX 复杂度的常规城内帧时间不稳定性。一颗超频到 4.7GHz 的 4790K 仍然撞上协调瓶颈，因为约束条件是指令每周期（IPC），而非时钟速度。
• i7-9700K + RTX 2080 Super，高画质，无光线追踪，DLSS 质量模式（v3.1） ：
  • 1080p：学院中行走：稳定约 60 fps。学院内载具：45–60 fps。开放世界载具：稳定 60 fps。战斗：55–60 fps。
  • 1440p：学院中行走：平均约 47 fps，范围 47–60 fps。学院内载具：降至约 40–50 fps。
  • 4K：学院模式与 1440p 相似。开放世界快速移动：45 fps 以上。战斗：45–50 fps。
    注意：此配置中光线追踪关闭 。没有为光线追踪支付视觉野心的代价 —— 但随着分辨率提高到 1440p 和 4K，GPU 成为共同因素时，瓶颈模式仍然存在。

这些数据共同说明：

跨越这三个硬件层级 —— 从 GTX 750Ti 到 RTX 2080 Super，最低画质到高画质，2GB 显存到 8GB 显存 —— 相同的模式重复出现：平稳遍历时正常，快速移动和边界跨越时下降，战斗 VFX 增加额外压力。瓶颈机制在所有层级都存在。

视觉野心确实带来了真实的成本 —— 光线追踪增加 RenderThread 压力，复杂 VFX 竞争 GameThread 预算，更高分辨率增加 GPU 帧时间。当这些成本与 GameThread 协调瓶颈结合时，帧预算缩水更快，天花板更早可见。正如 @Phantom_Tempest 所描述的：“视觉野心放大了引擎中已有的约束。”

但约束本身无论如何都存在。关闭视觉野心会降低严重程度，但不会消除架构瓶颈。正确的表述不是“Kuro 对画质太激进了，所以游戏卡顿” —— 而是：Kuro 的视觉野心使得一个已有的架构问题在更多硬件层级上、更频繁地暴露出来。

GTX 750Ti 的数据使之具体化：一块无法运行光线追踪、无法处理高画质的显卡，运行在最低人群密度下 —— 仍然表现出相同的卡顿特征。引擎架构是地板（下限）。视觉设置决定你多快能撞到它。

[檀越tanyue]

啊对对对我不用业界成熟的负载调整和热点加载方案一定是因为引擎底层限制而不是人已经用了十几二十年但是我没能力抄作业

[檀越tanyue]

“优化差”的真正含义 —— 以及为何对比比看起来更难

原文

When someone says WuWa is poorly optimized, the implicit benchmark is usually one of two things: “Cyberpunk runs smoothly at >=60fps, why doesn’t WuWa?” or “Genshin, AKE is smooth, why isn’t this?”

Both comparisons miss what WuWa is actually trying to do simultaneously.

Consider the full constraint stack Kuro is operating under:

• Open-world game with large, continuously loaded environments
• 3A visual ambition — lighting, geometry complexity, and effect density comparable to high-budget PC titles
• Dense populated cities with potentially hundreds of active NPC and interaction entities, some with AI behavior trees and scripting logic
• Combat-focused design requiring tight input latency, complex VFX, and simultaneous physics — all of which share the same GameThread budget
• Cross-platform — PC, PS5, iOS, Android, Mac — each with different GPU families, memory constraints, and scheduler behaviors
• Wide hardware range from flagship phones to budget Android devices, requiring config tuning that serves everyone
• Live-service 6-week cadence shipping new characters, areas, and systems continuously
• UE4 as foundation — a general-purpose engine not designed for any of these specific requirements in combination

No other game is currently doing all of these things together on UE4. Not Hogwarts Legacy (offline, no mobile, simpler combat). Not Tower of Fantasy (lower visual bar). Not Genshin (different engine, different architecture, lower graphical ceiling). The honest answer to “is WuWa poorly optimized compared to games in the same constraints?” is that there are no games in the same constraints to compare against.

Before concluding that WuWa’s performance is worse than it should be, you need to find another UE4 game that is simultaneously open-world, 3A visual fidelity, live-service at 6-week cadence, combat-heavy with complex VFX, cross-platform from mobile to PC, AND supporting a wide hardware range from budget devices to flagships. Until that comparison exists, the claim that Kuro’s optimization is below some reasonable baseline is not supported.

What we can say is that WuWa is running near the ceiling of what its engine architecture allows, given everything it’s attempting. That ceiling is real, it’s engine-level, and no external team has demonstrated how to escape it in a comparable context.

Cyberpunk runs on REDEngine — purpose-built for open-world performance by a studio that spent a decade constructing it. RDR2 runs on RAGE — over twenty years of iteration for dense open-world environments. These are not performance comparisons. They are comparisons between a general-purpose engine under pressure and custom infrastructure designed specifically to avoid that pressure.

The honest comparison is UE4 vs UE4: Hogwarts Legacy shipped CPU-bound in dense areas with Warner Bros. budget. PUBG — not an open-world game, but the longest-running UE4 title at scale — has required deep engine code modifications since 2017 per PlayerUnknown’s own words (“we’ve had to do a lot of changes to core engine code to make stuff work on that large a scale” — Rock Paper Shotgun), and community reports of micro-stutter and frame pacing instability persist across multiple years of that investment. As noted by @Phantom_Tempest, who has followed PUBG’s performance history closely: “so far I have only found PUBG as the highest likely candidate [for escaping UE4 limits], but nothing explicit yet outside of claims for modifying deep engine code.” Tower of Fantasy, the closest genre match, has faced performance complaints throughout its life. No clearly comparable UE4 open-world live-service title has publicly demonstrated a complete escape from this pattern.

One additional layer compounds everything: cross-platform support. WuWa ships on PC, iOS, Android, PS5, and Mac. Every optimization decision, every config value, every shader tradeoff has to work across GPU families from Adreno to Mali to Apple to desktop AMD and Nvidia, across devices from 6GB RAM phones to 64GB workstations. This is a constraint that single-platform games simply do not face, and it makes every “why not just fix X” question significantly harder to answer.

The accurate statement is not “Kuro failed to optimize something other studios got right.” The accurate statement is: hardware is not keeping pace with the technical debt and engine limitations that accumulate when a project of this visual ambition runs on this architecture, in a live-service deployment model that makes deep infrastructure changes nearly impossible.

That is a different diagnosis from “the devs are lazy.” And it points toward very different expectations.

One concrete data point grounds this: a game with genuinely poor optimization cannot be playable on an i5-4690 with DDR3 RAM and a GTX 750Ti 2GB — hardware from 2014 running below minimum spec. WuWa is. That is not the behavior of a game where engineers didn’t try. It is the behavior of a game where engineers worked within real constraints and still delivered a scalable experience across a hardware range few AAA titles attempt.

That said, the architectural context described in this analysis provides justification for current performance given current constraints — not a blank check for future patches. As C# migration matures, as MagicDawn integration deepens, as Tencent’s full backing enables longer-term architectural investment, the acceptable threshold shifts. If future cities released under significantly better resource conditions — v4.x, v5.x and beyond — exhibit the same Pattern A severity as Startorch Academy, the architectural constraint argument weakens and implementation quality becomes the more honest explanation. Startorch was a first-of-its-kind stress test for WuWa’s engine. Future cities at comparable density will not have that excuse. That is the bar Kuro now needs to clear.

机翻

当有人说《鸣潮》优化差时，隐含的基准通常是以下两者之一：“《赛博朋克》以 >=60fps 流畅运行，为什么《鸣潮》不行？”或者“《原神》、《无限大》很流畅，为什么这个不行？”

这两种比较都忽略了《鸣潮》同时尝试完成的任务。

请考虑 Kuro 在其下运作的完整约束栈：

• 开放世界游戏，拥有大型、持续加载的环境
• 3A 级视觉野心 —— 光照、几何复杂度、特效密度堪比高预算 PC 游戏
• 密集的城市区域，可能有数百个活跃的 NPC 和交互实体，部分带有 AI 行为树和脚本逻辑
• 以战斗为中心的设计，要求低输入延迟、复杂 VFX 以及同步物理 —— 所有这些共享同一个 GameThread 预算
• 跨平台 —— PC、PS5、iOS、Android、Mac —— 每个平台有不同的 GPU 家族、内存限制和调度器行为
• 硬件范围极广，从旗舰手机到低预算 Android 设备，需要为所有人调整配置
• 长期服务的六周发布节奏，持续推出新角色、新地区和新系统
• 以 UE4 为基础 —— 一个并非为上述任何特定需求的组合而设计的通用引擎

目前没有任何其他游戏在 UE4 上同时做到所有这些事情。不是《霍格沃茨之遗》（离线、无移动端、战斗更简单）。不是《幻塔》（视觉标准较低）。不是《原神》（不同引擎、不同架构、图形天花板更低）。对“《鸣浪》是否比处于相同约束下的游戏优化更差”的诚实回答是：没有处于相同约束下的游戏可以用来比较。

在断定《鸣潮》的性能表现比应有水平更差之前，你需要找到另一款同时满足以下条件的 UE4 游戏：开放世界、3A 级视觉保真度、六周节奏的长期服务、以战斗为主且 VFX 复杂、从移动端到 PC 跨平台、同时支持从低端设备到旗舰机型的广泛硬件范围。在这组比较存在之前，“Kuro 的优化低于某个合理基线”的说法是没有依据的。

我们能够说的是，考虑到《鸣潮》正在尝试的一切，它已经运行在其引擎架构所允许的天花板附近。这个天花板是真实存在的，是引擎层面的，并且没有任何外部团队在可比的上下文中证明过如何逃脱它。

《赛博朋克》运行在 REDEngine 上 —— 由一个花费十年构建它的工作室为开放世界性能专门打造。《荒野大镖客2》运行在 RAGE 上 —— 为密集开放世界环境迭代了超过二十年。这些不是性能比较。它们是在压力下的通用引擎与专门为避免这种压力而设计的自研基础设施之间的比较。

诚实的比较是 UE4 对 UE4：《霍格沃茨之遗》在华纳兄弟的预算下，在密集区域仍然受限于 CPU。《绝地求生》—— 虽然不是开放世界游戏，但却是规模最大的长期运行 UE4 游戏 —— 根据 PlayerUnknown 本人的说法，自 2017 年以来就需要对引擎代码进行深度修改（“我们不得不对核心引擎代码进行大量更改，才能使游戏在如此大规模下工作”—— Rock Paper Shotgun），并且社区关于微卡顿和帧时间不稳定的报告在这么多年的投入后依然存在。正如长期密切关注《绝地求生》性能历史的 @Phantom_Tempest 所指出的：“到目前为止，我只发现《绝地求生》是最有可能逃脱 UE4 限制的候选者，但除了修改深度引擎代码的说法外，还没有明确证据。”在品类上最接近的《幻塔》，在其整个生命周期中一直面临性能方面的抱怨。没有任何一个明确可比的、使用 UE4 的开放世界长期服务游戏，曾公开展示过完全摆脱这种模式。

还有一个层面会复合所有问题：跨平台支持 。《鸣潮》同时在 PC、iOS、Android、PS5 和 Mac 上发布。每一个优化决策、每一个配置值、每一个着色器权衡，都必须在从 Adreno 到 Mali 到 Apple 再到桌面 AMD 和 Nvidia 的 GPU 家族上工作，在从 6GB 内存手机到 64GB 工作站的设备上工作。这是单平台游戏根本不会面临的约束，也使得每一个“为什么不直接修 X”的问题都变得难以回答得多。

准确的表述不是“Kuro 未能搞定其他工作室做对的事情”。准确的表述是：当一个拥有如此视觉野心的项目在这个架构上、在几乎不可能进行深度基础设施变更的长期服务部署模型下运行时，硬件并未能跟上累积起来的技术债务和引擎限制。

这是与“开发者懒惰”不同的诊断。它指向的是非常不同的预期。

一个具体的数据点能够说明问题：一个真正优化差的游戏，不可能在一台 i5-4690、DDR3 内存、GTX 750Ti 2GB —— 运行在低于最低规格的 2014 年硬件上 —— 仍然可玩。《鸣潮》做到了。这不是工程师没有努力的游戏行为。这是工程师在真实约束下工作，仍然在很少 AAA 游戏敢尝试的硬件范围内交付了可扩展体验的游戏行为。

话虽如此，本文分析中所描述的架构上下文，为当前约束下的当前性能提供了合理性依据 —— 但并不是给未来版本开了空白支票。随着 C# 迁移的成熟、MagicDawn 集成的深化、以及腾讯全面支持带来的长期架构投入能力，可接受的阈值会发生变化。如果未来在资源条件显著改善的情况下发布的新城市（v4.x、v5.x 及更高版本）仍然表现出与始源学院相同的模式 A 严重程度，那么架构约束的论点就会变弱，实现质量将成为更诚实的解释。星炬学院是对《鸣潮》引擎的首次此类压力测试。未来密度相当的城市将不再有这个借口。这就是 Kuro 现在需要跨越的标杆。

[檀越tanyue]

宝了个贝的越往后槽点越多你凭什么说我优化差，哼

[檀越tanyue]

TL;DR

《鸣潮》为什么会卡顿 —— 简短版

原文

The game’s performance in dense cities is bottlenecked at the GameThread — UE4’s central coordination point that all game logic must pass through. WuWa does use UE4’s TaskGraph worker thread system, but the coordination and synchronization overhead at the GameThread remains the ceiling when scene density is high. More CPU cores don’t solve this. My benchmark (i7-12700KF + RTX 5070, city traversal, no FG): GPU at 54–58% average while CPU max thread hits 97–100%. The GPU is waiting, not the bottleneck.

Think of it like a highway with eight lanes — but only one toll booth. All traffic has to merge and pass through that single point before anything can move forward. Add more lanes and the jam doesn’t get better. That toll booth is the GameThread. Startorch Academy has hundreds of NPCs, buildings with active interaction logic, and complex ambient systems all trying to pass through it simultaneously. The thread saturates. Everything waits.

Why can’t they just fix it?

Because the toll booth is part of how Unreal Engine 4 was designed. It’s not a bug Kuro wrote — it’s the architectural foundation that every UE4 game is built on. Hogwarts Legacy has the same problem. So does Tower of Fantasy. No clearly comparable UE4 open-world live-service title has publicly demonstrated a complete escape from this pattern.

What is Kuro actually doing?

Patching consistently — performance improvements appear in nearly every major update. And quietly migrating the scripting layer from TypeScript (which uses V8’s garbage collector) to C# (a runtime with incremental, low-pause GC). That migration is confirmed by runtime logs, binary analysis, and datamine evidence. It’s expensive and invisible to players — and they’re doing it anyway while maintaining a 6-week content schedule.

The bottom line

“Dev lazy” doesn’t explain why Hogwarts Legacy had the same stutter pattern on a Warner Bros. budget. “Engine ceiling + live-service technical debt” does. The claim that Kuro’s optimization is below par requires a comparable game — UE4, open-world, live-service, cross-platform, combat-heavy — to benchmark against. No public example clearly matching that comparison set has been demonstrated yet.

---

If you want the full technical breakdown of why each of these things happens at the architecture level — keep reading from the top.

机翻

游戏在密集城市中的性能瓶颈在于 GameThread —— 这是 UE4 的核心协调点，所有游戏逻辑都必须经过它。《鸣潮》确实使用了 UE4 的 TaskGraph 工作线程系统，但当场景密度较高时，GameThread 上的协调和同步开销仍然是天花板。更多 CPU 核心解决不了这个问题。我自己的基准测试（i7-12700KF + RTX 5070，城市遍历，不开帧生成）：GPU 平均利用率 54–58%，而 CPU 最大线程达到 97–100%。GPU 在等待，它并不是瓶颈。

把它想象成一条八车道的高速公路 —— 但只有一个收费站。所有车辆必须先汇合并通过那个单点，才能继续前进。增加更多车道并不会缓解拥堵。那个收费站就是 GameThread。始源学院里有成百上千的 NPC、带有活跃交互逻辑的建筑，以及复杂的周边系统 —— 它们都在试图同时通过这个单点。线程饱和了。一切都在等待。

为什么他们不直接修好它？

因为这个收费站是虚幻引擎 4 设计方式的一部分。它不是 Kuro 写出的 bug —— 而是每一款 UE4 游戏所构建的架构基础。《霍格沃茨之遗》有同样的问题。《幻塔》也是。没有任何一个明确可比的、使用 UE4 的开放世界长期服务游戏，曾公开展示过完全摆脱这种模式。

Kuro 实际上在做什么？

持续打补丁 —— 几乎每个大版本更新都有性能改进。同时，他们正在悄悄地将脚本层从 TypeScript（使用 V8 的垃圾回收器）迁移到 C#（一种具有增量、低暂停 GC 的运行时）。这个迁移已被运行时日志、二进制分析和数据挖掘证据所证实。它成本高昂且对玩家不可见 —— 而他们在维持六周内容发布节奏的同时，仍在做这件事。

结论

“开发者懒惰”无法解释为什么《霍格沃茨之遗》在华纳兄弟的预算下也出现了相同的卡顿模式。“引擎天花板 + 长期服务技术债务”可以。关于 Kuro 优化不达标的论断，需要一个可比较的游戏 —— UE4、开放世界、长期服务、跨平台、重战斗 —— 作为基准。目前还没有公开的例子能明确满足这一比较集。

如果你想要了解为什么这些事情会在架构层面发生的完整技术解析 —— 请从头开始阅读。

[檀越tanyue]

宝了个贝的谁说的架构问题不能优化？平衡负载这不是程序员入门必修课？

[檀越tanyue]

本分析的局限性

原文

This analysis relies on datamined configuration files from Arikatsu/WutheringWaves_Data, personal benchmark captures (CapFrameX, i7-12700KF + RTX 5070 — two sessions: Huanglong and Startorch Academy), community-reported hardware traces, official Unreal Engine documentation, and community profiling data.

On the Puerts/V8 claim: This is now supported by direct evidence. Runtime log files (Client.log and multiple Client-backup-*.log) explicitly record V8 initialization, Puerts module loading, and V8 version strings on every launch. String extraction from Client-Win64-Shipping.exe yields identifiers including Puerts, PuertsJsEnv, KuroPuerts, TypeScriptGeneratedClass, and multiple /Game/Aki/TypeScript/ paths. FModel inspection of pak contents (via the community AES key archive at https://github.com/ClostroOffi/wuwa-aes-archive) reveals the ScriptAssemblies directory containing C# runtime assemblies deployed alongside the Puerts layer. This claim is confirmed, not inferred.

On the C# migration: The infrastructure is confirmed in datamine (aki_base.csv v2.8+, _csharp directories). The ScriptAssemblies pak contents confirm the C# runtime is deployed. Content migration is ongoing — the config files remain partially populated.

The 175ms and 245ms frame spike interpretations as GC pause events are consistent with V8’s documented behavior but cannot be confirmed without scripting VM profiler access. Both spikes are real and measured from hardware data. Their cause is the most technically consistent explanation available given the absence of GPU and thermal correlation.

The causal attribution between GameThread saturation and culling failure (Section 5) represents the most architecturally consistent explanation for the data, but cannot be fully separated from implementation-quality contributions without codebase-level profiler access.

On the customized UE4 build: Community engine config analysis reveals r.Streaming.UsingKuroStreamingPriority — a cvar not present in stock UE4’s streaming system — further confirming the engine has been substantially modified beyond a standard integration. Its documented behavior (controlling retention vs. load priority separately, with game-specific tradeoffs for different asset types) is consistent with a custom streaming pipeline built on top of the base UE4 framework.

Where direct evidence is unavailable, claims are labeled as inferred.

机翻

以下是“Limitations of This Analysis”（本分析的局限性）部分的中文翻译：

---

本分析的局限性

本分析依赖于来自 Arikatsu/WutheringWaves_Data 的数据挖掘配置文件、个人基准测试数据（CapFrameX，i7-12700KF + RTX 5070 —— 两次会话：瑝珑和星炬学院）、社区报告的硬件追踪、官方虚幻引擎文档以及社区性能剖析数据。

关于 Puerts/V8 的声明：目前已得到直接证据支持。运行时日志文件（Client.log 及多个 Client-backup-*.log）在每次启动时都明确记录了 V8 初始化、Puerts 模块加载以及 V8 版本字符串。从 Client-Win64-Shipping.exe 中提取的字符串包含 Puerts、PuertsJsEnv、KuroPuerts、TypeScriptGeneratedClass 以及多个 /Game/Aki/TypeScript/ 路径。通过 FModel 检查 pak 内容（借助社区 AES 密钥归档 https://github.com/ClostroOffi/wuwa-aes-archive）揭示了 ScriptAssemblies 目录，其中包含与 Puerts 层一起部署的 C# 运行时程序集。该声明确认属实，而非推断。

关于 C# 迁移：基础设施已在数据挖掘中得到确认（aki_base.csv v2.8+ 版本、_csharp 目录）。ScriptAssemblies 的 pak 内容证实 C# 运行时已部署。内容迁移正在进行中 —— 配置文件仍部分填充。

将 175ms 和 245ms 帧时间尖峰解释为 GC 暂停事件，这与 V8 文档记录的行为一致，但如果没有脚本 VM 性能分析器的访问权限则无法确认。这两个尖峰是真实的，并且是通过硬件数据测量得到的。在缺乏 GPU 和温度相关性的情况下，它们的原因是目前技术上最一致的解释。

GameThread 饱和与剔除失效之间的因果归因（第 5 节）是对数据在架构上最一致的解释，但如果没有代码库级别的性能分析器访问权限，则无法与实现质量方面的贡献完全区分开。

关于定制 UE4 构建：社区引擎配置分析发现了 r.Streaming.UsingKuroStreamingPriority —— 这是一个在原生 UE4 流式系统中不存在的 CVar —— 进一步证实该引擎已被大幅修改，远超标准集成。其文档记录的行为（分别控制保留与加载优先级，针对不同资产类型进行游戏特定的权衡）与在原生 UE4 框架之上构建的自定义流式管线一致。

在缺乏直接证据的地方，相关声明均已标注为“推断”。

[檀越tanyue]

你这文最大的局限性就是给库洛洗地的时候没藏好屁股，还暴露了技术力低下的事实

[檀越tanyue]

下面是一些没什么实质内容的更新文档，就不翻译了，感想等晚上回来再写

[随机的名字]

文章基本是看日志文件结构什么的推断出来的，准确不到哪去

少数能看或者说准确的是即使在 12700k+5070 这种算是高配u和卡的情况下，跑图也仅有 40帧的好成绩。

和什么根本没有什么多核优化

[檀越tanyue]

就是来洗地的，我已经很努力了但是这坨屎山铲不掉啊，闭口不谈这屎山怎么来的

[水肥战士]

我自己就是Java程序员，他这里高并发问题犯了很多非常新手的错误，比如为了并发不出错而长时间占用锁或者并发区，导致原本可以并行的任务不得不串行执行——于是就用不到其他的CPU核心。这是因为对并发过程不了解导致的，发生这种情况除了人员不熟练之外，就是没有时间做仔细分析，库洛要赶工期，我认为两者兼有。
库洛这样子搞真不如老老实实用unity（C#），C++是具有高度灵活性的语言，上下限都很高，工具链，头文件，运算符重载，STL……每一个都是坑，再这样下去只能把整个团队都拖跨。

[檀越tanyue]

这种时候就得请出老蔡了

[取名好烦]

看不太懂。
这个分析是怎么得出来的，莫非有什么办法能拿到源码？如果不能看到源码，怎么推断出上述结论呢？

[檀越tanyue]

因为这是不需要源码也能看出来的结论，虽然用很唬人的说法包装了起来，但核心就是我库洛已经在假装很努力优化了，你凭什么说我优化不好

[取名好烦]

诸如【两套程序语言两套素材】这种问题是怎么发现的？这个听起来太奇怪了吧？
——以及，它还有抢救风险吗？看上述都能找到问题原因了为什么不能优化呢？

[檀越tanyue]

请见4.2迁移，从ts→c#就是程序语言变更，一般来说稳定的底层是不需要更改的，比如老米一直是使用自家魔改的unity，编程语言也相当稳定。放心，wuwa没有抢救风险，不然3.0的包不会爆炸飞起，准确的说，他从ts迁移到c#，就是为了解决滥用ts导致的大量旧实体销毁和进入新地图加载新实体导致性能开销过大的问题，但是显然没解决 这种问题得从底层开始重构一个良好的环境，但是库洛即没人也没钱啊