megboyzzandClaude
f631a3a0a4
sub_4F3704 (resource lookup by name) is 18.8% of load-time samples and does a linear strcmp scan over 6232 entries because the game's own hash cache is disabled (*(self+8) == 0, confirmed by a live probe: 320,000+ calls per load). Attempt 1 crashed the process: guest strings were read through G2H and scanned for a NUL with no bounds check, so a bad offset walked off the end of the mapped region (SIGSEGV, SEGV_ACCERR at a host address). Attempt 2 was memory-safe (uc_mem_read everywhere, length and count caps, every cache hit verified against live guest memory, falls through to the guest on any doubt) but caused a visible frame-rate drop on the prologue loading screen. The cause was a design flaw the earlier probe log had already shown and I misread: the cache was keyed on the table ADDRESS, yet this game reuses one address for different tables (35 and 59 entries alternating in the log). The descriptor comparison therefore marked the index stale on nearly every call, and each rebuild re-read all ~6232 entry strings byte-by-byte - far more work than the scan it replaced. Kept in the tree, unregistered, with both mistakes documented. The fix for a third attempt is to key the cache on the DESCRIPTOR CONTENTS rather than the address, so alternating tables each keep their own index, plus bulk string reads instead of per-byte. Co-Authored-By: Claude <noreply@anthropic.com>