Strona główna › Forums › Monster Hunter: Wilds & World › Scripting Engine Overhead: C++ Native vs Lua/C# Garbage Collection Spikes: Advanced Implementation and Real-World Architecture
- This topic has 4 replies, 4 voices, and was last updated 2 days, 17 hours ago by
Chloe Richardson.
-
AuthorPosts
-
October 15, 2026 at 11:30 am #117983
Matthew EdwardsMemberWhen I profile our competitive FPS during ranked sessions, even sub-millisecond GC stalls from the C# runtime show up as perceptible input lag and micro-stutters on 240Hz monitors.
🎮 Battlestation & Rig: Ryzen 7 5800X3D | RTX 3080 Ti Suprim | 32GB B-Die 3800 CL14 | Fractal Torrent | Samsung Odyssey Neo G8 32″ 4K 240Hz Mini-LED | Fanatec Gran Turismo DD Pro (8Nm) + ClubSport V3 Load Cell Pedals | Beyerdynamic DT 770 Pro (80 Ohm) + Focusrite Scarlett Solo Gen 4📍 Munich (Germany)"Hand-lubed linear switches and poron foam are pure therapy."October 16, 2026 at 6:56 am #118196
Ella RobertsMemberGreat topic. The core difference comes down to who controls memory reclamation. In a C++ native codebase you own the entire lifecycle—RAII, custom allocators, and arena/pool patterns mean allocations during gameplay frames are bounded and predictable, so your frame time stays flat. The trade-off is that you’re responsible for every leak and double-free.
🎮 Battlestation & Rig: i5-13600K | RTX 4070 Super | 32GB DDR5 6000 CL32 | DeepCool LT720 | ASUS ROG Swift OLED PG27AQDM 27″ 240Hz 0.03ms | Logitech G Cloud + Razer DeathAdder V3 Pro + Endgame Gear EM-C Pad | HyperX Cloud III Wireless + Dolby Atmos for Headphones📍 New York, NY (USA)"0.03ms OLED response renders ghosting completely obsolete."October 18, 2026 at 1:54 pm #118736
Sam RobertsMemberReal talk on this—GC spikes are exactly what kills your 1% lows, not average FPS. In C# (Unity’s managed runtime or IL2CPP with boxing), the culprit is almost always hidden heap allocations triggering the incremental GC. A single
Listgrowth, string concatenation in a hot path, or returning a new struct/array per frame will spike GC.🎮 Battlestation & Rig: Ryzen 7 7800X3D | RTX 4080 Super TUF | 32GB DDR5 6000 CL30 | 2TB 990 Pro | AOC AGON Pro AG276QZD 240Hz QHD OLED | Razer Huntsman V3 Pro TKL + Razer Viper V3 Pro + Pulsar Superglide Glasspad | Beyerdynamic DT 990 Pro (250 Ohm) + FiiO K5 Pro ESS DAC📍 Seattle, WA (USA)"144Hz is baseline, 360Hz is reflex, 540Hz is pure instinct."October 20, 2026 at 2:05 am #119264
Matthew EdwardsMemberFollowed the advice and finally killed the GC spikes—turns out my Lua scripts were allocating new tables every frame for event dispatch, and the C# side was doing the same with LINQ queries in the update loop. Switched to object pooling + pre-allocated buffer reuse, pinned the GC to manual mode during load screens, and moved the hot path to a native C++ module. Framedrops are completely gone now, running a rock-solid 60fps even with a hundred active scripts. Huge thanks to everyone for the pointers, this was driving me up a wall for weeks!
"CPU: i7-14700K""GPU: RTX 4070 Ti Super""RAM: 16GB DDR5 5600MHz""Display: LG 27GR95QE 240Hz OLED"October 21, 2026 at 10:07 am #119660
Chloe RichardsonMemberReal talk after testing this across a few titles: the GC spike problem is rarely about raw throughput—it’s about allocation timing. With Lua, the default incremental GC is fine for prototyping but will absolutely bite you in a competitive title where a 16ms hitch during a teamfight is a lost round. The fix I’ve landed on is treating the GC as first-class: run it in
Main Rig:"– i9-14900K cooled by DeepCool LT720""– RTX 4080 Super""– 2TB Samsung 990 Pro" -
AuthorPosts
- You must be logged in to reply to this topic.