Blog de Vincent Brabant : NetBeans, Java et autres

Un article de vbrabant    6 Commentaires

J’avais déjà « joué » pas mal avec le profiler de NetBeans à la maison, et même préparé une démo pour le NetBeans Days de Paris, qui fut finalement faite pas Roman Strobl, pour des raisons de logistique.

Mais la semaine passée, j’ai pu utilisé le profiler de NetBeans pour un vrai projet.

Nous avions déjà utilisé un profileur, payant, sur notre projet. Mais il ne nous avait pas trop éclairé. Est-ce qu’il était mal configuré, Est-ce qu’on ne savait pas l’utiliser ? Je ne sais pas. Tout ce que je sais, c’est que la documentation concernant le profileur, c’est un classeur, et qu’il n’a pas l’air évident de le configurer (ce profileur s’installe sur les machines unix où tourne les serveurs d’applications, et est géré par d’autres équipes).

Mais, malgré tout, nous avions tout de même eu une piste sur un composant bien précis.

J’ai alors proposé l’idée d’utiliser le profileur de NetBeans. Ne sachant même pas si cela allait marcher (pas la même version du JDK, …)
J’ai donc installé le Profiler Pack de NetBeans , chargé les sources du composant, modifier les fichiers de configurations propres au composant, écrit une classe qui appelait toujours la même méthode dans une boucle infinie (la méthode étant le point d’entrée principal de notre composant). Tout cela en 1/2 heure à peine.
J’ai donc lancé le profileur sur l’application, et commencé à prendre des « snapshots » du composant, pour voir l’évolution. Il est bien d’attendre un peu pour prendre des snapshots, question de s’assurer que les classes qui doivent se charger le soient et ne viennent pas trop fausser les résultats.

Et bien, croyez-le ou pas, il n’a pas fallu longtemps pour savoir où était le problème. Je me souviens avoir dit à mon collègue, « donne moi une heure et je te dis où est le problème », et ce fut en effet le cas. Lorsqu’il est revenu de sa réunion, 1 heure après, je pouvais lui montrer du doigts la cause principale de tous nos problèmes: MessageFormat

A chaque fois que l’on loggue quelque chose à l’aide de log4j, log4j donne la main à notre classe responsable du Layout. Et pour « formatter » notre ligne de log, on utilise la classe MessageFormat.

En gros, on avait ceci:

Date d = new Date();
DateFormat df = new ISOxxxDate(); //classe de Log4J pour formatter la date sous forme yyyy-MM-dd HH:mm:ss:SSS avec un timezone de 0).
String line = MessageFormat.format("{0}|{1}|{2}|",new Object[] {df.format(d), correlationId, message}); 
out.println(line);

Et le profileur de NetBeans a montré que la majorité du temps était utilisé par

MessageFormat.format(pattern, argument)

et non à écrire dans le fichier (logiquement, ce sont les I/O qui prennent le plus de temps).

Si vous jetez un oeil à ce que fait cette méthode, vous voyez qu’elle fait ceci:

    public static String format(String pattern, Object ... arguments) {
        MessageFormat temp = new MessageFormat(pattern);
        return temp.format(arguments);
    }

A chaque fois qu’on appelle la méthode statique MessageFormat.format, la méthode crée un nouvel objet MessageFormat avec comme argument le pattern qu’il va parser et valider, pour ensuite formatter les arguments selon le pattern.

On a donc remplacé

Date d = new Date();
DateFormat df = new ISOxxxDate(); //classe de Log4J pour formatter la date sous forme //yyyy-MM-dd HH:mm:ss:SSS avec un timezone de 0).
String line = MessageFormat.format("{0}|{1}|{2}|",new Object[] {df.format(d), correlationId, message}); 
out.println(line);

par

Date d = new Date();
DateFormat df = new ISOxxxDate();
String line = df.format(d)+"|"+correlationId+"|"+message+"|"; 
out.println(line);

Une fois cela fixé, on a encore refait tourner le profileur qui a mis en évidence d’autre problème de MessageFormat ailleurs.
Finalement, nous avions un code qui tournait +- 3 fois plus vite qu’auparavant.
Et si nous n’avions pas eu de profileur, nous n’aurions jamais trouvé.

Mes collègues sont du coup parti à la recherche d’un profileur, gratuit, pour WSAD 5.1 (basé sur Eclipse 2.x), mais jusqu’à présent sans succès. Ils ont bien fait tourné un profileur, mais bien qu’on sachait maintenant où était le problème, nous n’avons jamais compris comment faire la relation entre les résultats de ce profileur, et le problème. Alors qu’avec le profileur de NetBeans, cela sautait vraiment aux yeux.