Allocations in Unity
Hello Noesis!
I've been looking at performance recently in our application and have been primarily focused on removing allocations. With regard to Noesis, a source of lots of allocations comes from the boxing/unboxing that happens when casting primitives like floats, ints, and enums to object.
Another source of allocations in Noesis is the marshalling of strings to/from the native Noesis dll.
I have modified the Noesis C# code quite a bit at this point to eliminate this garbage:
- I'm using a "variant" struct that wraps all the primitive types to avoid the major sources of boxing/unboxing allocations
- I've inserted a cache to re-use strings that were being marshalled from native code to avoid those allocations
- In a few cases, I'm recycling/reusing event arguments to avoid allocations.
So, I have a couple questions:
First, I would happily share this code back with y'all because I would prefer not to maintain it! :D. Would y'all be interested in seeing the changes I've made and considering integrating them?
Second, I'm still concerned about the overall performance in my Unity application. In theory, I can access your native APIs from native code using Unity's Burst compiler, but I end up extremely limited with some of the types I can use in that context (for example, there are no managed objects in burst, so I don't have simple things like string (there are alternatives)). The main part of my code that I would like to run "native" would be updating the data model.
Would appreciate thoughts/feedback!
thanks,
sam
I've been looking at performance recently in our application and have been primarily focused on removing allocations. With regard to Noesis, a source of lots of allocations comes from the boxing/unboxing that happens when casting primitives like floats, ints, and enums to object.
Another source of allocations in Noesis is the marshalling of strings to/from the native Noesis dll.
I have modified the Noesis C# code quite a bit at this point to eliminate this garbage:
- I'm using a "variant" struct that wraps all the primitive types to avoid the major sources of boxing/unboxing allocations
- I've inserted a cache to re-use strings that were being marshalled from native code to avoid those allocations
- In a few cases, I'm recycling/reusing event arguments to avoid allocations.
So, I have a couple questions:
First, I would happily share this code back with y'all because I would prefer not to maintain it! :D. Would y'all be interested in seeing the changes I've made and considering integrating them?
Second, I'm still concerned about the overall performance in my Unity application. In theory, I can access your native APIs from native code using Unity's Burst compiler, but I end up extremely limited with some of the types I can use in that context (for example, there are no managed objects in burst, so I don't have simple things like string (there are alternatives)). The main part of my code that I would like to run "native" would be updating the data model.
Would appreciate thoughts/feedback!
thanks,
sam
Re: Allocations in Unity
Yes, of course. Could you please create a new ticket with all the changes? We are definitely interested in the integration.First, I would happily share this code back with y'all because I would prefer not to maintain it! :D. Would y'all be interested in seeing the changes I've made and considering integrating them?
So far, we haven't tried DOTS or Burst compiler but that's something we want to do. Could you please elaborate about what parts related to Noesis could benefit from this? I assume you are updating the whole data model per frame? In this case I am not sure how the property change notifications interfere with the optimizations, but a solution could be have a first pass, with pure data, optimized by Burst and then copy the data (only the changes + notification) to Noesis.Second, I'm still concerned about the overall performance in my Unity application. In theory, I can access your native APIs from native code using Unity's Burst compiler, but I end up extremely limited with some of the types I can use in that context (for example, there are no managed objects in burst, so I don't have simple things like string (there are alternatives)). The main part of my code that I would like to run "native" would be updating the data model.
Please, let us know more about it. If necessary we could have a call too.
Who is online
Users browsing this forum: No registered users and 7 guests