bsimser
commented
5 years ago Original comment by Joris Huijbregts (Bitbucket: jjahuijbregts, ).
The saving and loading system is one-directional, so you can replace it with your own solution if needed. By default, JSON is used, but there's also an integration with EasySave 2.
The ReflectionUtility.GetAllClassesWithAttribute is only used in the editor; Do you have a stack trace or performance profile to compare this to?
What data would you expect to be pooled? Inventory pro doesn't often create / destroy objects, so pooling these objects would only increase the memory use of the game a lot, which might not be ideal for memory restricted platforms like iOS / Android.
Original report by Anonymous.
Re-implement everywhere where it uses reflection. It's a huge bottleneck. The ReflectionUtility.GetAllClassesWithAttribute is just one example of a massive bottleneck. It's extremely disconcerting to now have a slow game because of an inventory system. Startup and shutdown times are now painfully slow when serializing and deserializing. Also provide a different default JSON serializer/deserializer, as this is twice as slow over a binary one, i.e. Easy Save. JSON is not one idea that should be borrowed from the business world for games--it's simply too slow. Put more time into optimization versus just trusting C# to be fast. Test with timing code during development as there are many slow spots. Use object pooling over instantiation and destroying, since this also is a performance issue for a production game. These are glaring issues when it comes to production games rather than just a demo.