Performances comparées
J'ai souvent vu sur les forums UML des personnes se plaindre des performances des modeleurs UML, j'ai donc décidé de comparer BOUML à d'autres modeleurs au début de son développement :
La façon la plus facile pour moi d'avoir un projet contenant un grand nombre de classes ayant (normalement) la même définition sous plusieurs modeleurs est de reverser des sources de Java JDK (1.4.2). En utilisant des sources disponibles par tout le monde, chacun peut ainsi comparer son modeleur à BOUML. Bien-sûr le reverse sous BOUML n'utilise pas de catalogue produit pas Java catalog, ce qui ne serait pas équitable. Tous les tests sont fait sans firewall ou détecteurs de virus actifs.
La première observation est que seul BOUML et Enterprise Architect permettent de reverser l'ensemble des sources de Java (c'est à dire les répertoires com, java, javax, launcher, org, sunw et leurs sous répertoires), les autres outils demandant généralement trop de mémoire. Dans le cas de Visual Paradigm et UModel il n'a pas été possible de sauver le résultât, dans le cas de starUML il n'a pas été possible de recharger le modèle !
Sur mon PC (Pentium 4, CPU 3Ghz et 512 Mb de mémoire) sous Windows XP, Bouml 2.25 reverse tout les sources de Java version 6 (update 1) en 6 minutes 40 secondes, la taille do processus quand tout est reverse est de 172 Mo. Le reverse créé 9425 classes, 48506 propriétés (attributs and relations) et 85939 opérations.
BOUML 2.2 versus Enterprise Architect 5.0
Test fait sur mon PC sous Windows XP, Pentium 4, CPU 3Ghz, 512 Mb de mémoire.
Enterprise Architect
n'a pas de phase de sauvegarde, toute modification impacte les fichiers
mémorisant le modèle (ce trouve cela très étrange,
car je considère que toute sauvegarde doit être explicite et choisie), aussi
j'ai regroupé les phases de reverse et de sauvegarde en une pour
donner le temps utilisé par BOUML. Evidemment je ne demande pas à
Enterprise Architect de créer automatiquement les diagrammes pour ne pas
le ralentir.
La séquence de test est :
- temps nécessaire pour reverser le répertoire java et tout ses sous répertoires et sauver le projet
- sortir, redémarrer l'outil
- temps nécessaire pour relire le modèle
- taille du processus
- temps nécessaire pour générer tout le code
| BOUML | Enterprise Arch. | Enterprise Arch. / BOUML | |
| Reverse+Sauvegarde | 51 sec | 11 min 25 | 13 |
| Lecture | 3 sec | 4 sec | 1 |
| Taille processus | 38 Mb | 31 Mb | 1 |
| Génération | 16 sec | 4 min 31 | 17 |
BOUML 2.2 versus Poseidon Professional Edition 3.1
Test fait sur mon PC sous Windows XP, Pentium 4, CPU 3Ghz, 512 Mb de mémoire.
Poseidon
est un gros consommateur de mémoire et de CPU, il a seulement été possible de
reverser le répertoire java.awt et ses sous répertoires.
J'ai demandé à Poseidon de ne pas produire les diagrammes.
La séquence de test est :
- temps nécessaire pour reverser le répertoire java.awt et ses sous répertoires
- temps nécessaire pour sauver le projet
- sortir, redémarrer l'outil (le démarrage de Poseidon est tè long, je ne l'ai pas compté)
- temps nécessaire pour relire le projet
- taille du processus
| BOUML | Poseidon | Poseidon / BOUML | |
| Reverse | 17 sec | 2 min 30 | 9 |
| Sauvegarde | 2 sec | 51 sec | 25 |
| Lecture | 0.7 sec | 49 sec | 70 |
| Taille processus | 17 Mb | 314 Mb | 18 |
Note : Il n'a pas été possible de mesurer le temps de génération de code, car Poseidon ne permet de générer les sources que pour un très petit nombre des classes du modèle.
BOUML 2.2 versus Rhapsody 6.0
Test fait sur mon PC sous Windows XP, Pentium 4, CPU 3Ghz, 512 Mb de mémoire.
Rhapsody
permet de reverser le répertoire java et ses sous répertoires.
La séquence de test est :
- temps nécessaire pour reverser le répertoire java et ses sous répertoires
- temps nécessaire pour sauver le projet
- sortir, redémarrer l'outil
- temps nécessaire pour relire le projet
- taille du processus
- temps nécessaire pour générer tout le code
| BOUML | Rhapsody | Rhapsody / BOUML | |
| Reverse | 47 sec | 6 min 17 | 8 |
| Sauvegarde | 4 sec | 28 sec | 7 |
| Lecture | 3 sec | 23 sec | 8 |
| Taille processus | 38 Mb | 165 Mb | 4 |
| Génération | 16 sec | 3 min 18 | 12 |
BOUML 2.2 versus Rose Enterprise 2002
Test fait sous Windows XP prof 2002, Pentium 4, CPU 2.8Ghz, 1 Gb de mémoire.
Rose
permet de reverser le répertoire java et ses sous répertoires.
La séquence de test est :
- temps nécessaire pour reverser le répertoire java et ses sous répertoires
- temps nécessaire pour sauver le projet
- sortir, redémarrer l'outil
- temps nécessaire pour relire le projet
- taille du processus
| BOUML | Rose | Rose / BOUML | |
| Reverse | 39 sec | 12 min 55 | 20 |
| Sauvegarde | 4 sec | 11 sec | 3 |
| Lecture | 2 sec | 17 sec | 7 |
| Taille processus | 38 Mb | 157 Mb | 4 |
Note : je n'ai pas mesuré la génération de code car celle-ci doit être demandée composant par composant !
BOUML 2.2 versus Visual Paradigm for UML 4.1
Test fait sur mon PC sous Windows XP, Pentium 4, CPU 3Ghz, 512 Mb de mémoire.
Visual Paradigm
permet de reverser le répertoire java et ses sous
répertoires, mais il n'a pas été possible de sauver
le projet : j'ai préférer tuer le processus après 11 minutes
car la taille mémoire était devenue énorme.
J'ai refais l'essai sur un PC ayant 1 Gb de mémoire, la sauvegarde
à pris 44 secondes mais en fait rien n'était sauvé : en essayant de
sortir VP demandait de sauver le projet, en répondant oui de nouveau
une attente de 44 secondes sans que rien ne soit sauvé et si on essaye de sortir
VP redemande de sauver le projet ! Si je refuse alors la sauvegarde (théoriquement
déjà faite deux fois) et qu'on recharge le projet ce dernier est vide !
il est donc seulement possible de reverser le répertoire java/awt et ses sous répertoires (et de sauver le résultat). La séquence de test est :
- temps nécessaire pour reverser le répertoire java.awt et ses sous répertoires
- temps nécessaire pour sauver le projet
- sortir, redémarrer l'outil
- temps nécessaire pour relire le projet
- taille du processus
- temps nécessaire pour générer tout le code
| BOUML | Visual P | Visual P / BOUML | |
| Reverse | 17 sec | 25 sec | 1.5 |
| Sauvegarde | 2 sec | 49 sec | 25 |
| Lecture | 0.7 sec | 21 sec | 30 |
| Taille processus | 17 Mb | 279 Mb | 16 |
| Génération | 6 sec | 12 sec | 2 |
Note : comme vous pouvez le voir, Visual Paradigm prend curieusement deux fois plus de temps pour sauver le projet que pour faire le reverse !
BOUML 2.15.4 versus starUML 5.0
Test fait sur mon PC sous Windows XP, Pentium 4, CPU 3Ghz, 512 Mb de mémoire.
starUML
permet de reverser tout les sources de java (mais il faut presque 40 minutes
alors que Bouml le fait en 3 minutes 35), de sauver le résultat mais pas de relire
le projet : sur mon PC j'ai préféré tuer le processus après
10 minutes.
Durant le reverse je demande à starUML de ne pas produire les diagrammes pour ne pas le ralentir.
La séquence de test est :
- temps nécessaire pour reverser le répertoire java et ses sous répertoires
- temps nécessaire pour sauver le projet
- sortir, redémarrer l'outil
- temps nécessaire pour relire le projet
- taille du processus
- temps nécessaire pour générer tout le code
| BOUML | starUML | starUML / BOUML | |
| Reverse | 57 sec | 5 min 5 | 5 |
| Sauvegarde | 4 sec | 8 sec | 2 |
| Lecture | 3 sec | 40 sec | 13 |
| Taille processus | 38 Mb | 165 Mb | 4 |
| Génération | 16 sec | 11 | 0.7 |
BOUML 2.15.4 versus UModel 2006
Test fait sur mon PC sous Windows XP, Pentium 4, CPU 3Ghz, 512 Mb de mémoire.
UModel
permet de reverser tout les sources de java (en 5 minutes alors Bouml
le fait en 3 minutes 35), mais il n'est pas possible de sauver le résultat :
sur mon PC j'ai préféré tuer le processus après 10 minutes
car la taille du processus était d'environ 1 Go.
Durant le reverse je demande à UModel de ne pas produire les diagrammes pour ne pas le ralentir.
La séquence de test est :
- temps nécessaire pour reverser le répertoire java et ses sous répertoires
- temps nécessaire pour sauver le projet
- sortir, redémarrer l'outil
- temps nécessaire pour relire le projet
- taille du processus
- renommer le répertoire contenant les sources reversés car on ne décide pas du répertoire de génération
- temps nécessaire pour générer tout le code, note : le corps des opérations n'est pas généré car il ne fait pas parti du modèle
| BOUML | UModel | UModel / BOUML | |
| Reverse | 57 sec | 50 sec | 0.9 |
| Sauvegarde | 4 sec | 34 sec | 9 |
| Lecture | 3 sec | 14 sec | 5 |
| Taille processus | 38 Mb | 115 Mb | 3 |
| Génération | 16 sec | 21 sec | 1.3 |
BOUML 2.2 versus Jude Professional version 5.1
Test fait sur mon PC sous Windows XP, Pentium 4, CPU 3Ghz, 512 Mb de mémoire.
Jude
permet de reverser le répertoire java et ses sous répertoires.
La séquence de test est :
- temps nécessaire pour reverser le répertoire java et ses sous répertoires
- temps nécessaire pour sauver le projet
- sortir, redémarrer l'outil
- temps nécessaire pour relire le projet
- taille du processus
- temps nécessaire pour générer tout le code
| BOUML | Jude | Jude / BOUML | |
| Reverse | 47 sec | 8 min 20 | 11 |
| Sauvegarde | 4 sec | 25 sec | 6 |
| Lecture | 3 sec | 33 sec | 11 |
| Taille processus | 38 Mb | 228 Mb | 6 |
| Génération | 16 sec | 6 min | 23 |
BOUML 4.12 versus Omondo studio edition 3.4.1
Test fait sur mon PC sous Windows XP, Pentium 4, CPU 3Ghz, 2.5 Gb de mémoire.
Omondo
est un des outils travaillant sous Eclipse, comme il est impossible d'utiliser Eclipse
avec seulement 512 Mo de mémoire j'ai largement étendu celle-ci en ajoutant
2 Go.
Les tests de performance du reverse Java on été faits sur Xerces 2.8.1 car Omondo n'a pu reverser le package Java : après 3 minutes l'application était totalement bloquée sans consommer de CPU, tuer le processus fût la seule issue. Le reverse est effectué par via un Reverse UML > Deep Reverse > XMI Backup
Pour m'adapter aux spécificités de l'outil j'ai modifié la séquence de test, celle-ci est :
- temps nécessaire pour reverser les sources de Xerces 2.8.1, sans tenir compte du temps pour importer le projet Java ni le compiler même si cela est obligatoire car Omondo travaille sur les binaires et non sur les sources
- taille du processus après le reverse (1)
- sauver, sortir, redémarrer l'outil en lisant le projet
- taille du processus (2)
- temps nécessaire pour remplir un diagramme de classes avec seulement les 10 classes du package xerces.impl.dtd.models tout en demandant de dessiner l'ensemble des relations existantes. Dans le cas de Bouml ce temps est si court qu'il n'est pas mesurable.
- taille du processus (3)
- sortir
- temps nécessaire pour redémarrer l'outil en lisant le projet et afficher le diagramme de 10 classes
- fermeture diagramme
- temps de réouverture du diagramme. Dans le cas de Bouml ce temps est si court qu'il n'est pas mesurable.
- temps pour effectuer des opérations de base comme déplacer une classe ayant des relations, modifier les options dessin pour montrer/cacher des membres de classe. Dans le cas de Bouml tout est immédiat.
| BOUML | Omondo | Omondo / BOUML | |
| Reverse | 33 sec | 13 min 48 | 25 |
| Taille processus (1) | 24 Mo | 420 Mo | 17 |
| Taille processus (2) | 24 Mo | 162 Mo | 7 |
| Diagramme de classes | < 0.1 sec | 1 min 50 | > 1000 |
| Taille processus (3) | 25 Mo | 330 Mo | 13 |
| Lecture | 1.5 sec | 1 min | 40 |
| Réouverture diagramme | < 0.1 sec | 10 sec | > 100 |
| Opérations basiques | ~ 0 sec | plusieurs sec | > 1000 |
