Cache caféine contre goyave
D'après ces micro benchmarks il s'avère que Caféine est bien plus rapide que Cache de goyave dans les opérations de lecture et d'écriture.
Quel est le secret de la mise en œuvre de la caféine? En quoi il diffère du cache de goyave?
Ai-je raison qu'en cas d'expiration programmée, la caféine utilise un exécuteur programmé pour effectuer les opérations de maintenance appropriées en arrière-plan?
La principale différence est que la caféine utilise des tampons en anneau pour enregistrer et rejouer les événements, tandis que Guava utilise ConcurrentLinkedQueue. L'intention était toujours de faire migrer la goyave et il était logique de commencer plus simplement, mais malheureusement, il n'y avait jamais d'intérêt à accepter ces changements. L'approche du tampon en anneau évite l'allocation, est bornée (avec perte) et moins coûteuse à opérer.
Les coûts restants sont dus à un décalage de conception. L'auteur original de MapMaker était enthousiasmé par les références logicielles comme solution aux problèmes de mise en cache en les reportant au GC. Malheureusement, même si cela peut sembler rapide dans les microbenchmarks, il a des performances horribles dans la pratique en raison de provoquer un thrashing du GC à l'arrêt du monde. La solution basée sur la taille a dû être adaptée à ce travail et ce n'est pas idéal. La caféine optimise en fonction de la taille et gagne également une table de hachage améliorée, tandis que la goyave gère la mise en cache des références plus élégamment.
La caféine ne crée pas ses propres fils pour la maintenance ou l'expiration. Il reporte le coût au commonPool, ce qui améliore légèrement les latences face à l'utilisateur mais pas le débit. Une future version pourrait tirer parti de CompletableFuture.delayedExecutor pour planifier le prochain événement d'expiration sans créer directement de threads (pour les utilisateurs qui ont une logique métier en fonction des notifications de suppression rapide).
ConcurrentLinkedHashMap et MapMaker ont été écrits en même temps et CLHM a des performances similaires à la caféine. Je crois que la différence est due à quels scénarios les concepteurs ont préféré et optimisé, ce qui a eu un impact sur la façon dont d'autres fonctionnalités seraient mises en œuvre. Il y a des fruits bas pour permettre à la goyave d'avoir un profil de performance similaire, mais il n'y a pas de champion interne pour conduire cela (et encore moins avec la caféine comme alternative préférée).