Forum Discussion
Oculus Platform Unity Integration Memory Optimization
Hi devs!
I'm a member of the Platform SDK team and I'm working on improving the memory usage of the Oculus Platfrom Unity integration.
I started to profile our memory usage and there is definitely room for improvement. However, since I don't have much experience developing Unity games, I'm not sure what kind of memory usage is acceptable.
Our thinking currently is that for much a the SDK, a small amount of heap allocated memory is acceptable. Things like getting achievement definitions, cloud saves, getting users, and the like probably won't be called every frame, and so hyper optimizing there isn't necessary. (Also, this allows our APIs for these things to be a bit more user friendly.)
However, things like VOIP and P2P networking shouldn't allocate at all, except during setup and teardown. Voice and networking are going to be called every frame, so no allocation is acceptable.
Does this make sense and seem reasonable?
Also, and insight you can give into how you determine what is acceptable per-frame allocation, and how you meet that is more than welcome.
Best,
Casey
I'm a member of the Platform SDK team and I'm working on improving the memory usage of the Oculus Platfrom Unity integration.
I started to profile our memory usage and there is definitely room for improvement. However, since I don't have much experience developing Unity games, I'm not sure what kind of memory usage is acceptable.
Our thinking currently is that for much a the SDK, a small amount of heap allocated memory is acceptable. Things like getting achievement definitions, cloud saves, getting users, and the like probably won't be called every frame, and so hyper optimizing there isn't necessary. (Also, this allows our APIs for these things to be a bit more user friendly.)
However, things like VOIP and P2P networking shouldn't allocate at all, except during setup and teardown. Voice and networking are going to be called every frame, so no allocation is acceptable.
Does this make sense and seem reasonable?
Also, and insight you can give into how you determine what is acceptable per-frame allocation, and how you meet that is more than welcome.
Best,
Casey
3 Replies
Replies have been turned off for this discussion
- The main issue is that the old version of mono used by Unity has a garbage collector that is non-compacting and non-generational. So small allocations last longer, inevitably add up to a full GC which is guaranteed to drop frames. Allocations of varying lifetimes also create bubbles in the heap which cannot be defragmented, which can even cause you to run out of memory eventually. (from experience on a shipped title: using unity for dedicated game servers is a mistake)
For one time loading this is certainly fine. It is not uncommon to manually trigger garbage collection immediately before and after loading data before rendering starts, which fixes all those problems because then you are not interleaving allocations with short and long lifetimes. If you can design the API so that any state you are storing until shutdown gets pre-allocated upfront, before any temp allocations, that helps.
Operations that are not every frame but must still be called many times, like getting room or user data, should avoid allocation on the managed heap where possible, otherwise you will see dropped frames eventually. Since the GC is not generational, even if it is not every frame you will build up a debt that eventually has to be paid. - Wow, that's really discouraging. My experience writing real-time code in a garbage collected language was in JavaScript on Chrome's V8. V8's garbage collector is good enough that you can allocate every frame, and performance doesn't suffer as long as you keep your allocations small enough.
- Read the wonderful series of posts on Unity memory management on GamaSutra for some in general advice. Even if the version of mono were updated to get at improved GC, the advice in the articles would still help a lot in performance tuning.
