LeftJoinModel conveniently joins roles from two models similarly as it's done in sql via LEFT JOIN, but in a dynamic way. It's already commonly used in the app. However access to "joined" roles from the right model is slower than access to roles from left model. The data(...) method complexity for right-side roles is O(n) where n is row count of the right model. It should work smoothly in most cases when the model is only displayed e.g. via ListView, even for thousands of entries. However in more complicated flows, where e.g. there is sorting or filtering relying on the right-side roles, the cumulative complexity may be high (like O(n^2 * log(n)) for sorting). For that reason it would be valuable to optimize the access time for right-side role from O(n) to amortized O(1). It can be done in various ways, starting from really simple cache, invalidated whenever source data is changed, to some more sophisticated caching taking into account particular operations like insert/remove/move. The API of LeftJoinModel shouldn't be changed.
It's a subject of further investigation, but this improvement may result in noticeable performance gain in some more complex flows with huge number of entries, e.g. in a wallet.
Description
LeftJoinModel
conveniently joins roles from two models similarly as it's done in sql viaLEFT JOIN
, but in a dynamic way. It's already commonly used in the app. However access to "joined" roles from the right model is slower than access to roles from left model. Thedata(...)
method complexity for right-side roles isO(n)
where n is row count of the right model. It should work smoothly in most cases when the model is only displayed e.g. viaListView
, even for thousands of entries. However in more complicated flows, where e.g. there is sorting or filtering relying on the right-side roles, the cumulative complexity may be high (likeO(n^2 * log(n))
for sorting). For that reason it would be valuable to optimize the access time for right-side role fromO(n)
to amortizedO(1)
. It can be done in various ways, starting from really simple cache, invalidated whenever source data is changed, to some more sophisticated caching taking into account particular operations like insert/remove/move. The API ofLeftJoinModel
shouldn't be changed.It's a subject of further investigation, but this improvement may result in noticeable performance gain in some more complex flows with huge number of entries, e.g. in a wallet.