Je travaille sur un projet d'amélioration de la performance. J'avais un doute, pendant que nous sommes pendant un processus, nous avons tendance à retrouver l'état actuel du DTO et de l'entité utilisée. Ainsi, pour cela, nous avons inclus la méthode Tostring () dans tous les pojos pour la même chose. J'ai maintenant mis en œuvre Tostring () de trois manières différentes qui suivent: -
public String toString() {
return "POJO :" + this.class.getName() + " RollNo :" + this.rollNo + " Name :" + this.name;
}
public String toString() {
StringBuffer buff = new StringBuffer("POJO :").append(this.class.getName()).append(" RollNo :").append(this.rollNo).append(" Name :").append(this.name);
return buff.toString();
}
public String toString() {
StringBuilder builder = new StringBuilder("POJO :").append(this.class.getName()).append(" RollNo :").append(this.rollNo).append(" Name :").append(this.name);
return builder .toString();
}
4 Réponses :
Utilisez le premier. Je vais expliquer pourquoi.
La vue naïve est d'utiliser le dernier. Il n'y a aucune raison d'utiliser le second. A qui étant dit, vous devez faire attention à ce type de micro-optimisation. Pourquoi? Parce que le compilateur le fera souvent cela pour vous. Donc, écrivez ce qui est le plus lisible et laissez le compilateur l'optimiser. donc la principale leçon ici est: Ne pas micro-optimise . finalement , cela n'a probablement pas l'un des 1 ou 3 que vous utilisez. Stringbuffer est identique à un StringBuilder Sauf dispose d'une performance Hit de Synchronisée serrures. Mais ne le mettez pas sur une ligne. C'est beaucoup plus lisible: Tostring () Les méthodes ne sont pas Tendez à utiliser un montant énorme dans une application. Plus couramment, ils sont utilisés dans des messages d'erreur, qui sont espèrent peu fréquents.
Pourquoi la peine d'utiliser un StressBuilder explicitement? Le premier formulaire utilisera une implicitement de toute façon et sans le cruft supplémentaire.
Je sais que le compilateur allumera la première version en troisième, mais c'est l'enfer de déboguer cette version générée, car ce qui se passe n'est pas ce que vous voyez dans votre code source, alors j'ai tendance à utiliser la troisième version.
@Seanizer Avez-vous souvent besoin de déboguer vos méthodes de ToString ()? D'habitude, je place un point d'arrêt sur une ligne d'une ligne dans mon ensemble et regardez les valeurs variables dans mon débogueur et cela me dit ce qui est susceptible de provoquer une exception.
@Seanizer: Vous pouvez prendre cette logique plus loin et affirmer que le seul moyen de rédiger un code est en montage, car c'est ce que "réellement arrive", n'est-ce pas? Non, je ne suis pas d'accord. L'abstraction est bonne. Ignorance de l'abstraction est mauvais, mais l'abstraction elle-même est bonne. Plus le mieux.
@Peter, @poly non, je ne débède pas souvent des méthodes de totrage, mais je débobile souvent des méthodes de bibliothèques tierces où la concaténation de la chaîne se produit dans un appel de méthode et je dois faire beaucoup de F5 / F7 dans Eclipse afin de ne pas manquer La déclaration réelle que je suis intéressé. Oui, l'abstraction est bonne, mais dans ce cas, l'abstraction a un prix qui me fait souvent bugement. Et le point de l'assembleur est hors de propos, car mon débogueur ne saisit heureusement pas les appels d'assembleurs. mais "ce qui se passe" était un mauvais choix de libellé, je suis d'accord
Celui avec le Si vous construisez une chaîne > À l'intérieur d'une boucle, alors plus souvent, vous devez utiliser simpliste (pas vrai toujours, mais c'est un bon RÈGLE OFFRES), sauf si vous faites un Une option souvent non considérée est d'utiliser Je trouve que c'est la version la plus lisible et la plus maintenue. est-ce plus rapide? Peut-être que oui peut-être que non. Cela n'a généralement pas d'importance pour les scénarios de cas d'utilisation courants pour quelque chose comme J'ai corrigé une erreur de syntaxe dans le code d'origine à partir de + est bien dans ce cas. C'est plus lisible, et il est tout aussi performant par rapport à la version StringBuilder / Stringbuffer , puisque elle ne se produit pas dans une boucle. stringbuilder . Utilise uniquement stringbuffer si vous avez besoin de la fonctionnalité synchronisée , qui n'arrive pas très souvent. + = avec une chaîne , vous n'avez pas vraiment besoin de stringbuilder / stringbuffer . < / p> questions connexes
A
string.format Option string. Format . Ça va chercher quelque chose comme ceci: tostring () . S'efforcer de lisibilité, optimiser uniquement si le profilage dit qu'il est nécessaire. Liens d'API
Java.Util.Formatter < / Code> Syntaxe
sur les littéraux de classe
this.class (qui ne compile pas) à this.getclass () . Voir aussi
"Est-ce plus rapide?" - presque certainement pas parce que le format doit analyser la chaîne de format et l'appelant doit allouer et remplir un tableau de varargs. Mais comme vous le dites, cela n'a probablement pas d'importance.
@Stephen: Oui, je serais très surpris si format est plus rapide, mais j'essaie de ne pas développer même un instinct de base pour ce genre de choses et de faire confiance à un profileur.
De plus, je pense que vous pouvez mettre en cache le nom de la classe dans un chaîne finale statique , mais je doute que cela ferait trop de différence. OP devrait utiliser un profileur et trouver un morceau de code réellement digne d'optimiser.
Utilisez le 1er 1, car il est plus lisible.
Mais sinon, peu importe.
Utilisation Le
stringbuilder et + Dans ce cas est équivalent, car le compilateur traduit l'opérateur surchargé + sur un Stringbuilder .
Stringbuffer sera plus lent, en raison de ses méthodes étant synchronisées , mais depuis synchronisé . (Voir Notes de publication JDK 6U14 pour en savoir plus sur l'analyse de l'évasion)
Whoa! Quel jeu d'exécution JVM synchra-t-il élision? C'est la première fois que j'ai entendu parler d'une fonctionnalité aussi (cool!)!
@polygenLubants depuis JDK 6U14 Il est disponible, mais pas par défaut, je pense. Voir Java.sun.com/javase/6/webnotes/6U14.htmlle_ A> pour savoir comment allumer.
pas si vite. "Malheureusement, l'optimisation basée sur l'analyse, qui a été activée dans la mise à jour 14, a été désactivée à nouveau dans la mise à jour 18 à rétablir à une date future."
L'analyse d'évasion est là en 6U20, mais je ne sais pas ce que cela fait avec cette analyse, car il ne semble pas la rendre plus rapide. ;)
Ceci est plus lisible imo
Peut-être que dans C # c'est comme ça, mais pas en Java. En outre, ceci.class ne compile pas.
En Java, c'est MessageFormat.Format (...) avec syntaxe de paramètres identique (j'utiliserais réellement cela.getclass (), pas getclass (). GetName (), pas besoin d'évaluer la totring avant qu'elle ne soit nécessaire). BTW, cette.Class ne compile pas autant que nombre déjà mentionné
Je suis sûr que vous pouvez écrire une référence en 2 minutes. Pourquoi devinez quand vous pouvez mesurer?
Le repère montrerait des résultats, oui, mais il est bon de connaître théoriquement ces choses.
Dupliqué possible de Concaténation StringBuilder VS String dans Tostring () en Java
"Je travaille sur un projet d'amélioration de la performance" - Utilisez un profileur et identifiez la section du code qui vaut vraiment la peine d'être examinée et optimisante.