Considérations sur les performances Dans Scala

Question

Scala s'appuie sur java.lang.String pour ses opérations String, mais il enrichit la classe de chaînes Java en ajoutant d'autres méthodes telles que .intersect entre autres Il en va de même pour int wrapper (Int) en Java , il y a aussi la classe RichInt.

Je me rends compte que le code suivant:

val stringOne: String = "teststring" 
val stringTwo: String = "string" 
stringOne.intersect(stringTwo) 

entraînera le compilateur scala à type de stringOne coulé à la classe StringOps afin qu'il ait accès à méthode Intersect

Je crains que ce pourrait entraîner des coûts de calcul sérieux Donc, quelqu'un peut-il me dire si cela est vrai et si oui, y a-t-il des façons d'optimiser ou d'éviter cette situation?

J'espère que ma question est logique, j'ai lu plusieurs livres, mais aucun ne répond à ces préoccupations Merci. :)

EDIT: Une question similaire a été posée et répondue here Je vous serais reconnaissant si quelqu'un pouvait répondre à ce sous l'angle de la mémoire ainsi

Answer 1

En général, il peut y avoir des impacts de performance de conversions implicites (par exemple pendant longtemps .isNaN était ~ 50% plus lent que java.lang.Double.isNaN). Cependant, si la classe convertie en est une classe de valeur, le compilateur JIT a beaucoup plus de facilité à supprimer le surcoût restant (généralement il n'y en a pas), vous pouvez toujours conserver une surcharge si vous avez une conversion implicite le compilateur JIT abandonne avant de supprimer toute la chaîne d'appels).

En tout cas, ce n'est pas la principale préoccupation ici. intersect est une méthode générique, donc il encapsulera tous les caractères de la chaîne. Cela va ralentir énormément les choses (probablement 5x ou plus) par rapport à une méthode qui est conçue pour ne prendre que Char.

La façon de dire ces choses est de regarder à travers les Scaladocs et voir où se trouve l'implémentation. intersect n'est pas sorti dans la feuille (StringOps); c'est tout le chemin du SeqLike, qui ne sait rien sur les personnages en particulier. (Bon, d'accord, pour être sûr que vous devez regarder le code source et/ou le benchmark, mais vous pouvez généralement obtenir une bonne idée du site de définition listé dans Scaladoc.)