alaa_wmde added a comment.
Before I change the description of this task. Here are my findings. Turns out
that `MapCacheLRU` used inside `BufferingTermIndex` is only per-object cache,
not really per-process. Meaning that two instances of `BufferingTermIndex` will
not actually share the cache (since they create their own instances of
`MapCachLRU` instances internally).
To test, you can try the running the following inside MW's `eval.php`:
$cache1 = new \MapCacheLRU( 5 );
$cache2 = new \MapCacheLRU( 5 );
$cache1->set( 'foo', 'is in cache 1' );
$cache2->set( 'bar', 'is in cache 2' );
$cache3 = new \MapCacheLRU( 5 );
var_dump( $cache1->toArray() );
/** output
/var/www/mediawiki/maintenance/eval.php(78) : eval()'d code:1:
array(1) {
'foo' =>
string(13) "is in cache 1"
}
*/
var_dump( $cache2->toArray() );
/** output
/var/www/mediawiki/maintenance/eval.php(78) : eval()'d code:1:
array(1) {
'bar' =>
string(13) "is in cache 2"
}
*/
var_dump( $cache3->toArray() );
/** output
/var/www/mediawiki/maintenance/eval.php(78) : eval()'d code:1:
array(0) {
}
*/
Since `PrefetchingPropertyTermLookup` and `PrefetchingItemTermLookup` already
implement such per-object in-memory caching through simple array, then the
increase in retrieved queries per second is probably not due to any caching
missing in these two classes.
TASK DETAIL
https://phabricator.wikimedia.org/T229407
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: alaa_wmde
Cc: Aklapper, alaa_wmde, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86,
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Jonas,
Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
