Fetching entries
I am wondering what the performance considerations are when calling methods such as `InventorySystem.ListItems()` or `EconomySystem.List()`.
Each player may have 100s of items in their inventory and even more available to purchase. Could these calls become a scaling issue? I have the impression that the entire inventory (or an itemSet) has to be serialized into a map, even if just one specific item is searched for.
Would it be possible to define more query properties beyond category for searching inventory items? For example: Creating a search index for properties similar to the storage list index, or by filtering via item set(s).
Personalizer
In the docs it is stated that “When any Hiro system needs configuration (every time GetAchievements(), GetEnergies(), or any Hiro call happens), the pipeline transforms that configuration before Hiro processes it”.
As we plan to have a large amount of economy, inventory, progression entries, etc. I am reluctant to to use the personalizer feature (especially for unlocking economy entries via progressions), as I am not sure how well it would scale performance wise.
Should I use the personalizer regardless or rather rely on the custom logic, for example to check which items can be purchased based on the progression system.
Hi @kroonhorstdino
We haven’t seen these become performance issues in production games built with Hiro. Our general advice is to use the systems as they are and profile first before optimisations.
Listing performance and query flexibility
For hundreds of items, the in-memory iteration cost is negligible, storage reads and network round-trips will be the bottleneck before any list processing. If profiling does show that ListInventoryItems is too slow for a specific use case, additional server-side filtering can be added via a custom RPCs, with the caveat that anything outside the standard Hiro Systems won’t have offline mode support out of the box.
Personalizer and progression-gated access
We recommend using the Personalizer for gated purchases, it runs server-side which means access rules are enforced authoritatively regardless of what the client does. If you gate visibility purely in client logic, a player can still call the Purchase RPC directly and the server will process it as long as they have sufficient currency. With the Personalizer, Hiro intercepts configuration before processing any request, so a disabled or unavailable item is never treated as purchasable for that player at the server level.
Personalizer performance at scale
GetConfig() produces a full deep clone of your economy config before your Personalizer receives it, so there are no shared state or race condition concerns. For a large catalog the iteration and field-setting logic in your Personalizer adds microseconds, it is rarely where bottlenecks live. The real cost to inspect is any storage read inside the Personalizer, such as a ListInventoryItems call to resolve player state, since I/O operations take more time than everything else in the function. If the Personalizer is adding meaningful latency, please share your profiling results to better understand where the bottlenecks are.