The mw.wikibase Lua functions getAllStatements and getBestStatements are expensive in the same way as getEntity, I believe: they have to load the whole entity from the database. (They’re slightly less expensive than getEntity in that not the whole entity has to be converted into a Lua table afterwards.) However, this expensiveness is incompletely modeled: the underlying entity accesses are counted by the PHP EntityAccessor (via RestrictedEntityLookup), and therefore more than entityAccessLimit calls will cause an error; however, they’re not counted against the “expensive (parser) function count”, unlike getEntity(), which calls php.incrementExpensiveFunctionCount(). I think this isn’t intentional.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T237884 mw.wikibase.getBestStatements is slow when used on objects with many properties | |||
| Open | None | T297412 Correctly mark getAllStatements and getBestStatements functions as expensive |
Event Timeline
Comment Actions
In production, both limits ($wgWBClientSettings['entityAccessLimit'] and $wgExpensiveParserFunctionLimit) are the same, 500; however, by default, the entity access limit is 250 while the expensive parser function limit is only 100. So maybe this is actually intentional? @hoo do you know?
If it is actually intentional that these calls are only counted against one of two access limits, then I think it should still be mentioned in the documentation that those functions are “expensive” in some sense (if not the specific “_x_ expensive parser function calls allowed” sense), and more “expensive” than some other functions like getLabel(), which can use the term store.