Comment améliorer les performances Guice au démarrage

Ok, je sais que mes calculs ne sont pas objectifs et ainsi de suite, mais de toute façon, je déteste attendre beaucoup de temps lors de l'exécution de mes tests unitaires:Comment améliorer les performances Guice au démarrage

Mon Guice application Swing faut compter environ 7 secondes pour initialiser. C'est un simple client IRC. À ce moment, aucune connexion n'est ouverte, je n'ai même pas encore appelé de classes java.io ou java.net. J'ai essayé d'affiner ce qui ne va pas et j'obtiens que 5,6 secondes (en moyenne) sont utilisées par Guice pour créer l'injecteur avec les 2 modules que j'utilise (un module normal et un construit avec FactoryModuleBuilder, installé dans le module d'origine).

Lorsque je supprime tous les modules (donc appel uniquement et exactement Guice.createInjector()), cela prend encore 3,5 secondes.

La version de Guice que j'utilise est la 3.0 rc2. Mon ordinateur n'est certainement pas le dernier, mais il n'est pas encore plus vieux que 3 ans. Alors, comment puis-je améliorer les performances de Guice, si possible?

Pour référence, voici la méthode principale que j'utilise, provoquant les 3,5 secondes. Les appels suivants prennent 0,01 secondes

public static void main(String[] args) { 

    long t = System.currentTimeMillis(); 
    Injector injector = Guice.createInjector(); 
    long t1 = System.currentTimeMillis(); 
    System.out.println(((t1 - t))/1000.0); 
}

Et le résultat

3.578

Source

2011-01-20 Olivier Grégoire

Il doit y avoir un problème avec votre ordinateur ou avec le RC. La mienne a 2 ans, j'utilise Guice 2, et vide 'Guice.createInjector()' prend 0.140 s lors de la première invocation. Guice est assez rapide, mais dans les tests unitaires, il est recommandé de ne pas utiliser DI, puisque vous pouvez le câbler manuellement la plupart du temps. – maaartinus

Pour l'enregistrement, vous devriez utiliser 'System.nanoTime()' plutôt que 'System.currentTimeMillis()' pour chronométrer les choses. 'System.currentTimeMillis()' est "horloge murale" ... le Javadoc pour ces méthodes explique un peu plus. Cela n'affectera certainement pas le moment ici de manière significative. – ColinD

Eh bien, au début, mes tests étaient avec nanoTime(). Mais quand j'ai vu le long temps de chargement, j'ai pensé que cela pourrait être lié à cette méthode, donc je suis revenu au (bon vieux) currentTimeMillis(). Puisque les résultats sont les mêmes avec les deux méthodes, je ne me suis pas soucié de le changer en nanoTime(). –

Vous ne devriez pas avoir besoin d'utiliser Guice dans les tests unitaires. Si vous avez besoin de l'utiliser, ils ne sont probablement pas vraiment des tests unitaires (qui testent les choses dans isolation) ou vous n'utilisez pas Guice correctement ou les deux.
Guice ne devrait certainement pas prendre un certain nombre de secondes pour démarrer à moins qu'il y ait quelque chose dans votre code causant quelque chose de bizarre. Sur ma machine (avec 3.0 rc2) il faut un peu plus de 100ms pour créer un Injector avec Guice.createInjector() et aucun module.

Source

2011-01-20 14:55:16 ColinD

Ok, ne pas vouloir falmebait, mais cela signifie-t-il que Guiceberry est un framework inutile? En ce qui concerne le deuxième point: je vais essayer sur mon ordinateur personnel dès que je reviens à la maison, mais en ce moment, c'est vraiment énervant. –

Quoi qu'il en soit, la raison pour laquelle je teste avec Guice est que j'ai besoin de tester mon module. C'est en fait pourquoi j'utilise Guice dans les tests unitaires. –

@ Frór: Personnellement, je n'utilise pas Guice dans les tests unitaires ... les tests de groupes de classes ensemble (c'est-à-dire les tests d'intégration, les tests de bout en bout) ont un sens pour utiliser Guice. Je n'ai pas utilisé Guiceberry alors je ne peux pas vraiment parler de ça. Quoi qu'il en soit, il y a des utilisations légitimes pour Guice dans les tests, donc je ne vais pas argumenter sur ce point plus. – ColinD

Comment améliorer les performances Guice au démarrage

Répondre

Questions connexes