Je tiens à examiner Scala et à répondre à une question fondamentale: en général, y a-t-il une différence de performance et d’utilisation de la mémoire entre Scala et Java?
Réponses
Trop de publicités?
Scala, il est très facile à utiliser d'énormes quantités de mémoire sans s'en rendre compte. C'est en général très puissant, mais peut parfois être gênant. Par exemple, supposons que vous disposez d'un tableau de chaînes de caractères (appelés array), et une carte à partir de ces chaînes de fichiers (appelés mapping). Supposons que vous voulez pour obtenir tous les fichiers qui sont dans la carte et viennent des chaînes de longueur supérieure à deux. En Java, on peut
int n = 0;
for (String s: array) {
if (s.length > 2 && mapping.containsKey(s)) n++;
}
String[] bigEnough = new String[n];
n = 0;
for (String s: array) {
if (s.length <= 2) continue;
bigEnough[n++] = map.get(s);
}
Ouf! Dur travail. En Scala, le plus compact de façon à faire la même chose, c'est:
val bigEnough = array.filter(_.length > 2).flatMap(mapping.get)
Facile! Mais, sauf si vous êtes assez familier avec la façon dont les collections de travail, ce que vous ne pourriez pas comprendre, c'est que cette façon de faire, cela a créé un extra intermédiaire array (avec filter), et un objet supplémentaire pour chaque élément du tableau (avec mapping.get, ce qui renvoie une option). Il crée également deux objets de fonction (une pour le filtre et l'autre pour le flatMap), mais c'est rarement un problème majeur puisque la fonction des objets de petite taille.
Donc, fondamentalement, l'utilisation de la mémoire est, à un niveau primitif, le même. Mais Scala les bibliothèques ont de nombreuses méthodes puissantes qui vous permettent de créer un nombre énorme d' (généralement de courte durée) des objets très facilement. Le garbage collector est généralement assez bien avec ce genre de déchets, mais si vous allez dans complètement inconscients de ce mémoire est utilisée, vous aurez probablement courir dans les problèmes plus tôt dans la Scala de Java.
Notez que l'Ordinateur Langues de Référence de Jeu Scala code est écrit dans un plutôt Java comme style pour obtenir Java à la performance, et donc a Java-comme l'utilisation de la mémoire. Vous pouvez le faire en Scala: si vous écrivez votre code pour ressembler à haute performance code Java, il sera haute performance Scala code. (Vous pouvez être en mesure de l'écrire dans une plus idiomatique à la Scala de style et toujours obtenir de bonnes performances, mais cela dépend des spécificités.)
Je dois ajouter que, pour la quantité de temps consacré à la programmation, mon Scala code est généralement plus rapide que mon code Java depuis en Scala, je peux obtenir la fastidieuse de la non-performance des composants critiques fait avec moins d'effort, et de passer plus de mon attention optimisation d'algorithmes et de code pour des pièces critiques.
Not Sleeping
Points
581
Je suis un nouvel utilisateur, donc je ne suis pas en mesure d'ajouter un commentaire à Rex Kerr réponse ci-dessus (ce qui permet aux nouveaux utilisateurs de "répondre", mais pas "comment" est une très curieuse règle btw).
J'ai signé simplement de répondre à la "ouf, Java est tellement verbeux et ce travail acharné" insinuation de Rex populaire de la réponse ci-dessus. Alors que vous pouvez bien sûr écrire plus concis code Scala, Java exemple donné est clairement gonflé. La plupart des développeurs Java code serait quelque chose comme ceci:
List<String> bigEnough = new ArrayList<String>();
for(String s : array) {
if(s.length() > 2 && mapping.get(s) != null) {
bigEnough.add(mapping.get(s));
}
}
Et bien sûr, si nous allons faire semblant que Eclipse ne pas faire plus de la réelle taper pour vous et que chaque personnage a sauvé vraiment fait de vous un meilleur programmeur, vous pouvez vous code ce:
List b=new ArrayList();
for(String s:array)
if(s.length()>2 && mapping.get(s) != null) b.add(mapping.get(s));
Maintenant, je n'ai pas seulement d'économiser du temps qu'il a fallu me taper plein de noms de variables et les accolades (libérant moi de passer plus de 5 secondes pour crois profondément à l'algorithmique pensées), mais je peux aussi saisir mon code de la dissimulation de concours et potentiellement gagner de l'argent supplémentaire pour les vacances.
Kevin Wright
Points
31665
Écrivez votre Scala comme Java, et vous pouvez vous attendre presque identique bytecode être émis avec presque la même métrique.
Écrire plus de "idiomatique", avec des objets immuables et des fonctions d'ordre supérieur, et il sera un peu plus lent et un peu plus grand. La seule exception à cette règle-de-pouce est lors de l'utilisation de générique des objets dont le type params utiliser l' @specialised d'annotation, ça va créer encore plus de bytecode qui peuvent dépasser de Java les performances en évitant les boxing/unboxing.
Il convient également de mentionner le fait que plus de mémoire / moins de vitesse est un compromis inévitables lors de l'écriture de code qui peuvent être exécutées en parallèle. Idiomatiques Scala code est beaucoup plus déclarative dans la nature que ce qui est typique du code Java, et est souvent un simple 4 caractères (.par), loin d'être parfaitement parallèles.
Donc, si
- Scala code prend 1,25 x plus de code Java dans un seul thread
- Il peut être facilement partagé sur les 4 cœurs (maintenant courante, même dans les ordinateurs portables)
- pour l'exécution en parallèle le temps de (1.24 / 4 =) 0.3125 x l'original Java
Voulez-vous dire alors que la Scala de code est maintenant relativement 25% plus lente, ou 3x plus rapide?
La bonne réponse dépend exactement comment vous définissez "performance" :)
Peter Knego
Points
57985
Le Langage De L'Ordinateur Repères De Jeu:
Test de vitesse java/scala 1.71/2.25
Test de la mémoire java/scala 66.55/80.81
Donc, cette repères dire que java est 24% plus rapide et scala utilise 21% plus de mémoire.
Tout-en-tout, c'est pas une grosse affaire et ne devrait pas d'importance dans le monde réel des applications, où la plupart du temps est consommé par la base de données et du réseau.
Bottom line: Si Scala fait de vous et de votre équipe (et les personnes qui prennent projet lorsque vous quittez) plus productif, alors vous devriez aller pour elle.
Seth
Points
450
D'autres ont répondu à cette question à l'égard de boucles serrées bien qu'il semble y avoir une évidente différence de performances entre Rex Kerr exemples que j'ai commenté.
Cette réponse est vraiment ciblée sur les personnes qui pourraient enquêter sur un besoin pour une boucle d'optimisation comme défaut de conception.
Je suis relativement nouveau à la Scala (environ un an), mais le sens, jusqu'à présent, c'est qu'il vous permet de reporter de nombreux aspects de la conception, de la mise en œuvre et l'exécution relativement facilement (avec assez d'arrière-plan de la lecture et de l'expérimentation :)
Différés Caractéristiques De Conception:
Différés Caractéristiques De Mise En Œuvre:
Exécution différée Caractéristiques: (désolé, pas de liens)
- Thread-safe paresseux valeurs
- Passer-par-nom
- Monadique trucs
Ces caractéristiques, pour moi, sont ceux qui nous aident à avancer sur le chemin rapide, serré applications.
Rex Kerr exemples diffèrent en ce que les aspects de l'exécution est différée. Dans l'exemple Java, l'allocation de la mémoire est différée jusqu'à ce que la taille est calculée en où la Scala exemple reporte la cartographie de recherche. Pour moi, ils semblent comme complètement différents algorithmes.
Voici ce que je pense que c'est plus des " pommes avec des pommes équivalent pour son Java exemple:
val bigEnough = array.collect({
case k: String if k.length > 2 && mapping.contains(k) => mapping(k)
})
Pas d'intermédiaire collections, pas de Option instances, etc.
Il conserve également la collection de type bigEnough's est de type Array[File] - Arrays' collect mise en œuvre sera probablement faire quelque chose le long des lignes de ce que M. Kerr code Java.
Le report de caractéristiques de conception que j'ai énumérés ci-dessus permettrait également de Scala, collection de l'API aux développeurs de mettre en œuvre rapide Tableau spécifique à recueillir mise en œuvre dans les futures versions sans casser l'API. C'est ce à quoi je fais allusion, avec sur le chemin de la vitesse.
Aussi:
val bigEnough = array.withFilter(_.length > 2).flatMap(mapping.get)
L' withFilter méthode que j'ai utilisé ici à la place de filter fixe l'intermédiaire de la collection de problème, mais il y a toujours l'Option de l'instance de problème.
Un exemple simple de la vitesse d'exécution des Scala est avec l'exploitation forestière.
En Java, on peut écrire quelque chose comme:
if (logger.isDebugEnabled())
logger.debug("trace");
En Scala, c'est juste:
logger.debug("trace")
parce que le paramètre de message de débogage dans la Scala de type "=> String" qui, je pense, comme un paramètre moins de fonction qui s'exécute lorsqu'elle est évaluée, mais dont la documentation appelle passe-par-nom.
EDIT { Les fonctions de Scala sont des objets si il y a un objet supplémentaire ici. Pour mon travail, le poids d'un banal objet vaut retrait de la possibilité d'un journal de message d'entrer inutilement évalué. }
Cela ne veut pas rendre le code plus rapide, mais il est plus susceptible d'être plus rapide et nous sommes moins susceptibles d'avoir l'expérience d'aller à travers et de nettoyage autres gens du code en masse.
Pour moi, c'est un thème récurrent au sein de la Scala.
Le code ne parvient pas à saisir pourquoi Scala est plus rapide si elle ne pointe un peu.
J'ai l'impression que c'est une combinaison de code de la réutilisation et le plafond de la qualité du code en Scala.
En Java, le code impressionnant est souvent forcé de devenir un gâchis incompréhensible et donc n'est pas vraiment viable au sein de la production de la qualité des Api comme la plupart des programmeurs ne serait pas en mesure de l'utiliser.
J'ai de grands espoirs que la Scala pourrait permettre à la einsteins parmi nous pour mettre en œuvre beaucoup plus compétente Api, potentiellement exprimés par les Dsl. Le core Api Scala sont déjà loin le long de ce chemin.
