Your first question about performance impact doesn’t have a simple answer. Well,
1.b. does: there’s no performance impact for the API because this is a UI feature to help with data input. In the API, you’re supplying the input data directly, so this feature isn’t in play. The answer to
1.a. is the more complicated one.
First off, I should mention that the “performance hit” happens once when a user opens the menu, just like when any other autocomplete is populated. The difference between when the feature is active or not is because you don’t need to type search characters that act like a filter, we’re potentially dealing with more data.
The higher the number of records that could populate the menu, the slower the menu is displayed, and the higher the potential performance impact is on the server. For example,
Version.entity could point to a myriad of possible values across entity types, which all need to be looked up, ordered, and then limited to the top 25. If you had
Shot.sg_sequence that had only 5 possible values, that would be super fast. We’ll generally suggest using this feature for a subset of entity or multi-entity fields that has a limited number of valid values such that it acts more like a list field but with entities. Enabling the feature on a field that has thousands of possible valid values, for example, diminishes the value as you’ll probably rarely see the entities you’re looking for and will need to type in search characters as if you hadn’t enabled the feature at all.
You should also view the performance impact through the lens of actual user interaction volume. If you’re enabling this feature on a field only visible by supervisors and infrequently used, the aggregate impact is lower than enabling it on a field frequently used by all artists.
As for what determines the first 25 (
2.) it is always determined by alphabetically sorting all the possible values whether this is an entity field, multi-entity field or polymorphic multi-entity field (like
Version.entity). As of this first implementation of the feature, the sorting behaviour isn’t configurable.
I don’t think we have technical documentation about the implementation of this feature, but I think the above should set you down the right path. If you have any follow-up questions, I’ll be happy to answer them.