6 ms·

Unity uses/used the standard boehm garbage collector [1] for over a decade, and it has been notorious for causing GC lag in games produced from that engine, not

Unity uses/used the standard boehm garbage collector [1] for over a decade, and it has been notorious for causing GC lag in games produced from that engine, noticeable in occasional sudden spikes of dropped framerate while the GC does a sweep at a layer of abstraction higher than Unity game developers can control directly. People went to extreme measures to avoid allocating memory in their games: manually pooling every in-game object & particle, not using string comparisons in C#, etc https://danielilett.com/2019-08-05-unity-tips-1-garbage-collection/ https://danielilett.com/2019-08-05-unity-tips-1-garbage-coll... Unity itself finally has a new system they're previewing to average out the GC spikes over time, so a game, say, never drops below 60fps: https://blogs.unity3d.com/2018/11/26/feature-preview-incremental-garbage-collection/ https://blogs.unity3d.com/2018/11/26/feature-preview-increme... As well, there is a new way of writing C# code for Unity called ECS that will avoid producing GC sweeps https://docs.unity3d.com/Packages/com.unity.entities@0.1/manual/index.html https://docs.unity3d.com/Packages/com.unity.entities@0.1/man... [1[ https://github.com/ivmai/bdwgc https://github.com/ivmai/bdwgc

jayd16 7y ago
That Unity was using that ancient collector was the main complaint. Switching to an incremental GC is long overdue. As for pooling objects, you'd go to those "extreme measures" as a matter of course in any other language as well. You wouldn't want to alloc and free every frame no matter the language.
- doomlaser 7y ago
  Yes. the boehm collector is the root of the problem for Unity's runtime. It's just the verbatim code from that repository in fact. But in other languages, such as C with standard libraries, you can still do common things like comparing stings and calling printf() without inadvertently triggering a dreaded GC sweep. Not so in Unity's C#. And allocating memory is fine during runtime when you are in control of the allocation and the cleanup, whereas in Unity, the sweeps are fully out of your control, expensive, and will just sometimes happen in the middle of the action
  - jayd16 7y ago
    You can just set the GC mode to disabled and run it manually. https://docs.unity3d.com/ScriptReference/Scripting.GarbageCollector.GCMode.html https://docs.unity3d.com/ScriptReference/Scripting.GarbageCo...
    - doomlaser 7y ago
      That API is new and was just added to 2018.3 in December, around the same time they started previewing the incremental garbage collector and promoting ECS. From Unity: > Being able to control the garbage collector (GC) in some way has been requested by many customers. Until now there has been no way to avoid CPU spikes when the GC decided to run. This API allows you disable the GC and avoid the CPU spikes, but at the cost of managing memory more carefully yourself. It only took them 14 years and much hand wringing from both players and developers to address :) A similar thing is going on with their nested scene hierarchy troubles, also releasing in 2018.3 with their overhaul to the prefab system, to sort of support what they call "prefabs" having different "prefabs" in their hierarchy without completely obliterating the children. What they have now is not ideal, but they're working on it. Prior to that, if you made. say, a wheel prefab and a car prefab, as soon as you put the wheels into your car prefab, they lost all relation to their being a wheel, such that if you updated the wheel prefab later, the car would still just have whatever you had put into the car hierarchy originally, which naturally has been the source of endless headaches and hacky workarounds for many developers.
      - jayd16 7y ago
        All true. However, even before you could disable the GC, you could ignore it as long as you weren't allocating and hit framerate. Unity isn't magic but the way people talk it's like Unity games don't exist.
        doomlaser 7y ago
        But things like this would happen, even from acclaimed developers, giving the engine a bad reputation among players: > The frame-rate difficulties found in version 1.01 are further compounded by an issue common with many Unity titles - stuttering and hitching. In Firewatch, this is often caused by the auto-save feature, which can be disabled, but there are plenty of other instances where it pops up on its own while drawing in new assets. When combined with the inconsistent frame-rate, the game can start to feel rather jerky at times. That studio is part of Valve now! > Games built in Unity have a long history of suffering from performance issues. Unstable frame-rates, loading issues, hitching, and more plague a huge range of titles. Console games are most often impacted but PC games can often suffer as well. Games such as Galak-Z, Roundabout, The Adventures of Pip, and more operate with an inherent stutter that results in scrolling motion that feels less fluid than it should. In other cases, games such as Grow Home, Oddworld: New 'n' Tasty on PS4, and The Last Tinker operate at highly variable levels of performance that can impact playability. It's reached a point where Unity games which do run well on consoles, such as Ori and the Blind Forest or Counter Spy, are a rare breed. https://www.eurogamer.net/articles/digitalfoundry-2016-firewatch-ps4-analysis https://www.eurogamer.net/articles/digitalfoundry-2016-firew... https://www.eurogamer.net/articles/2016-02-10-firewatch-dev-assures-a-ps4-framerate-fix-is-on-the-way https://www.eurogamer.net/articles/2016-02-10-firewatch-dev-... Hopefully as the engine continues to improve dramatically, this kind of thing will be left in the past

jayd16 7y ago

That Unity was using that ancient collector was the main complaint. Switching to an incremental GC is long overdue. As for pooling objects, you'd go to those "extreme measures" as a matter of course in any other language as well. You wouldn't want to alloc and free every frame no matter the language.

doomlaser 7y ago
Yes. the boehm collector is the root of the problem for Unity's runtime. It's just the verbatim code from that repository in fact. But in other languages, such as C with standard libraries, you can still do common things like comparing stings and calling printf() without inadvertently triggering a dreaded GC sweep. Not so in Unity's C#. And allocating memory is fine during runtime when you are in control of the allocation and the cleanup, whereas in Unity, the sweeps are fully out of your control, expensive, and will just sometimes happen in the middle of the action
- jayd16 7y ago
  You can just set the GC mode to disabled and run it manually. https://docs.unity3d.com/ScriptReference/Scripting.GarbageCollector.GCMode.html https://docs.unity3d.com/ScriptReference/Scripting.GarbageCo...
  - doomlaser 7y ago
    That API is new and was just added to 2018.3 in December, around the same time they started previewing the incremental garbage collector and promoting ECS. From Unity: > Being able to control the garbage collector (GC) in some way has been requested by many customers. Until now there has been no way to avoid CPU spikes when the GC decided to run. This API allows you disable the GC and avoid the CPU spikes, but at the cost of managing memory more carefully yourself. It only took them 14 years and much hand wringing from both players and developers to address :) A similar thing is going on with their nested scene hierarchy troubles, also releasing in 2018.3 with their overhaul to the prefab system, to sort of support what they call "prefabs" having different "prefabs" in their hierarchy without completely obliterating the children. What they have now is not ideal, but they're working on it. Prior to that, if you made. say, a wheel prefab and a car prefab, as soon as you put the wheels into your car prefab, they lost all relation to their being a wheel, such that if you updated the wheel prefab later, the car would still just have whatever you had put into the car hierarchy originally, which naturally has been the source of endless headaches and hacky workarounds for many developers.
    - jayd16 7y ago
      All true. However, even before you could disable the GC, you could ignore it as long as you weren't allocating and hit framerate. Unity isn't magic but the way people talk it's like Unity games don't exist.
      - doomlaser 7y ago
        But things like this would happen, even from acclaimed developers, giving the engine a bad reputation among players: > The frame-rate difficulties found in version 1.01 are further compounded by an issue common with many Unity titles - stuttering and hitching. In Firewatch, this is often caused by the auto-save feature, which can be disabled, but there are plenty of other instances where it pops up on its own while drawing in new assets. When combined with the inconsistent frame-rate, the game can start to feel rather jerky at times. That studio is part of Valve now! > Games built in Unity have a long history of suffering from performance issues. Unstable frame-rates, loading issues, hitching, and more plague a huge range of titles. Console games are most often impacted but PC games can often suffer as well. Games such as Galak-Z, Roundabout, The Adventures of Pip, and more operate with an inherent stutter that results in scrolling motion that feels less fluid than it should. In other cases, games such as Grow Home, Oddworld: New 'n' Tasty on PS4, and The Last Tinker operate at highly variable levels of performance that can impact playability. It's reached a point where Unity games which do run well on consoles, such as Ori and the Blind Forest or Counter Spy, are a rare breed. https://www.eurogamer.net/articles/digitalfoundry-2016-firewatch-ps4-analysis https://www.eurogamer.net/articles/digitalfoundry-2016-firew... https://www.eurogamer.net/articles/2016-02-10-firewatch-dev-assures-a-ps4-framerate-fix-is-on-the-way https://www.eurogamer.net/articles/2016-02-10-firewatch-dev-... Hopefully as the engine continues to improve dramatically, this kind of thing will be left in the past