devoo - info pour les ours

Le but est de pouvoir faire des calculs à la fois précis et utilisant peu de ressource sur une grille, donc sur des traitements long (ie : qui entraine beaucoup de mesures)

L'idée de base est de détourner l'utilisation des assertions en Java 1.5 pour pouvoir activer désactiver une fonction de mesure de temps. Il existe d'autres possibilités mais elles ne correspondent pas à nos besoin :

Première idée, selon la valeur d'une variable définie, alors on executerais la fonction de calcul de temps ou non.

Deuxième idée, la plus simple, utiliser une classe ou une autre selon les cas qui contiendrait une fonction de mesure de temps réelle ou vide selon son type. Cette possibilité semble interessante mais elle cause un surcout puisqu'on fait réellement un appel de fonction.

Troisième idée, pour réduire le léger surcout, est de marquer les lignes de mesure de temps grâce à un marqueur special et de lancer un script qui se chargera de commenter ou décommenter le code entre ces balises le cas échéant.

Quatrième idée, plus propre mais beaucoup plus couteuse, est de réaliser le design pattern Observable-Observer. Et d'activer l'Observer que si on en a besoin. Le problème est que c'est une mesure indirecte et donc plus couteuse.

Cinquième idée est d'utiliser la spécialisation pour introduire la mesure de temps. Si on a un traitement a() de la classe A, sans mesure de temps, alors on peut la spécialiser en une classe B de méthode b() qui fera :

b(){
 debutMesureDuTemps();
 super.a();
 finMesureDuTemps();
}

Le principal problème est qu'il ne permet pas d'ajouter facilement des mesures de temps puisqu'il faut découper préalablement les méthodes en bloc. Et requiert donc plus d'appel de méthode et donc un surcout.

La solution proposé est de s'appuyer sur le méchanisme des assertions, utilisé normalement pour tester les pré/post-conditions. Par default, Java desactive les assertions, c'est à dire qu'il faut compiler son programme avec l'option '-ea' ou -eanbleassertion' pour qu'elles soient "executées". Sinon elles ne le seront pas et il n'y aura pas de surcharge.

Il faut bien préciser ici que cette utilisation est border-line dans la mesure ou, ce n'est qu'une utilisation détournée. Pour valider cette méthode, deux possibilités : * Analyse du bytecode

L'analyse du bytecode montre ceci dans le cas ou l'on utilise les assertions :

31      getstatic #23 <Field assertionCost/WithAssertion.$assertionsDisabled Z>
34      ifne 52
37      aload_2
38      invokevirtual #49 <Method assertionCost/TimeMesuration.start ()Z>
41      ifne 52
44      new #51 <Class java/lang/AssertionError>
47      dup
48      invokenonvirtual #52 <Method java/lang/AssertionError.<init> ()V>
51      athrow

La ligne 31 permet de demander de récuper la variable statique assertionsDisabled crée par le compilateur (qui est de type boolean : Z). Si les assertions ne sont pas desactivées (ligne 34) alors on execute la fonction de temps start() de la classe TimeMesuration qui retourne un boolean. Si la valeur retournée n'est pas "true", alors on crée une exception (ligne 44) et on la lance (ligne 51).

Problème par rapport à l'idée de base : - la possibilité que l'assertion soit fausse implique un deuxième test qui vérifie le retour (le premier vérifie que les assertions sont activés). Bref on se retrouve avec 2 tests, ce qui finalement semble plus ou moins revenir au même qu'un test classique

Il me semble bizarre que l'on doive tester si les assertions sont desactivés. Soit : - il faut compiler le biniou avec une option particulière pour ne pas faire ce test - soit il y a une option qui permet de désactiver les assertions en fonction des classes

EDIT Il est en fait vraissemblable que ce soit le classLoader de la JVM qui en chargeant le bytecode décide de zapper les assertions ou non.

* Des benchs

Encore une fois les résultats sont bizarre. J'essairais de retester demain avec une machine dédié.

Bref bilan mitigé. Cela m'a permis de plongé un peu dans le bytecode. J'en suis pas plus avancé concernant les mesures de temps.