Outils pour utilisateurs

Outils du site


public:optimisation:test_perf_ergo

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

public:optimisation:test_perf_ergo [2019/11/29 13:26] (Version actuelle)
slh@ens-lyon.fr créée
Ligne 1: Ligne 1:
 +===== Tests performance et ergonomie gros corpus =====
 +
 +  * voir le ticket http://​forge.cbp.ens-lyon.fr/​redmine/​issues/​2675
 +
 +==== Résumé RAM/​CPU/​Divers ====
 +
 +=== Commandes ===
 +
 +  * la RAM allouée à la JVM semble suffisante pour l'​ensemble des commandes testées ci-dessous
 +  * grosse consommation CPU de javaw.exe lors du redraw des graphiques JFreeChart lorsque les graphiques contiennet beaucoup d'​entités\\ -> NOTE Dev : vérifier que Java2d utilise bien le GPU, accélération matérielle
 +  * goulet d'​étranglement sur les requêtes CQP "​[]"​ (déjà discuté avec MD + tests de fix dans CQPLexicon)
 +  * grosse consommation CPU et RAM de Rterm (jusqu'​à 1.4Go sur des grosses CA)
 +  * l'​annulation des commandes utilisant R ne semble pas fonctionner (en attente de la réponse du process Rterm.exe je pense car si on kill le process, l'​annulation se fait bien)\\ -> Note dev : est-ce qu'on ajouterait pas un kill de Rterm.exe dans l'​annulation + un relancement ?\\ -> pourquoi on passe par Rterm et pas directement par R\\ -> A noter que la RAM de Rterm est gérée hors Java, pour la consommation total de la RAM de TXM il faut donc cumuler javaw.exe + Rterm.exe\\ -> mais comment est gérée la RAM utilisée par cqpjni.dll ? la lib utilise celle allouée à javaw.exe ?
 +
 +=== Import ===
 +
 +  * non testé
 +
 +==== Corpus ELTECFRAORIG ====
 +
 +  * 79 fichiers source
 +  * Nombre de mots : 7 671 635
 +
 + ​-Xms512m -Xmx2048m
 + ​Niveau de log à INFO, "mode avancé"​ non coché, "​ajouter des commentaires techniques"​ coché.
 + ​Paramètres par défaut des commandes quand ce n'est pas précisé.
 + Pics Ram JVM durant la session de travail : ~800M/​~1200M of ~1800M
 +
 +**Légende :**
 +  * RAS = Rien à signaler en termes de performance ou ergonomie
 +  * + -> OK
 +  * - -> Pas OK
 +
 +=== Problèmes généraux ===
 +
 + - D'une manière générale, il manque des logs dans la console. (il faudrait rediriger les messages des sous-tâches du Job/​Progression vers la console ?)
 + - L'UI des éditeurs reste accessible lors des calculs long ce qui peut provoquer des bugs sur certaines commandes
 +
 +=== Chargement du binaire ===
 +
 +Chargement du corpus binaire au format 0.8.0 ELTECFRAORIG.txm...
 +->
 +Chargement du corpus binaire ELTECFRAORIG.txm au format 0.8.0...
 +
 +ELTECFRAORIG corpus chargé(s).
 +->
 +Corpus ELTECFRAORIG chargé(s).
 +
 +=== Propriétés ===
 +
 + + RAS
 + + vMax = 1000 : RAS
 + - Titre de l'​onglet non traduit "​Properties"​
 + - Titre du sous-onglet "​Parametres"​ => "​Paramètres"​
 + - mettre "​Propriétés"​ tout en bas du menu contextuel ? + virer "​Préférences"​ ?
 +
 +=== Navigateur ===
 +
 + + RAS
 + - à l'​ouverture de l'​éditeur la zone des paramètres avancés est dépliée mais elle est vide
 +
 +=== Edition ===
 +
 + + RAS
 +
 +=== Sous-corpus ===
 +
 + - ne marche sur aucun corpus plus depuis la dernière update
 +
 +=== Lexique ===
 +
 + - un peu long : ~1.2 sec
 + - UI commence à ramer lors du tri à partir de 20 000 résultats par page
 +
 +=== Index ===
 +
 + + RAS : faire
 + + RAS : [frlemma="​faire"​] | [frlemma="​voir"​]
 +
 +
 +=== Cooccurrence ===
 +
 +- "​faire"​ : très long ~20 sec
 +- "​pas"​ : très long ~20 à 40 sec
 +- javaw.exe et Rterme.exe utilisent énormément de CPU
 +- manquent des logs
 +
 +=== Progression ===
 +
 + + calcul RAS
 + - JFC: l'​éditeur de graphique rame pas mal dès qu'il y a une plusieurs courbes avec de nombreux points
 + - JFC : la mise en évidence de nombreux points fait également complètement ramer l'UI\\ -> Note dev : revoir la 2e passe de tracé des mises en évidence
 + - JFC: javaw.exe utilise beaucoup de CPU lors du déplacement,​ zoom dans le graphique
 +
 +=== Wordcloud ===
 +
 + + RAS
 +
 +=== Partition ELTECFRAORIG_text_booktitle (79 parties) ===
 +
 + + RAS
 +
 +== Dimensions de partition ==
 +
 ++ RAS niveau des performances
 +
 +== Table lexicale ==
 +
 + - très long ~8 à 12 sec
 + - ne semble pas venir du calcul de fdist mais de la requête "​[]"​ de chaque CQPLexicon, est-ce qu'on ne pourrait ajouter la property à la query ?
 + - finalement voir : http://​forge.cbp.ens-lyon.fr/​redmine/​issues/​2673
 + -- Fmin = 1, Vmax = 10 000
 + -- très long ~8 à 12 sec
 + -- tri sur colonne qui rame
 +
 +== Index ==
 +
 + - "​faire",​ "​pas",​ "​lui"​ : RAS
 + - "​ind*"​ sort "​in"​ en résultat !
 +
 +== Spécificités ==
 +
 + - manquent des logs
 + - extrêment long : ~1 min 23 sec\\ -> Note dev : la table lexicale créée et en fmin = 1 et fmax = 9999999
 + - Rterm.exe mange beaucoup de CPU
 + - l'UI rame
 + - depuis une table lexicale (2/200), long ~10 sec
 + - depuis une table lexicale (1/10000), long ~45 sec
 + - problème du rafraichissement des colonnes à l'​ouverture de l'​éditeur sous Windows qui peut prendre plusieurs secondes.
 +Le pack des colonnes basé sur la taille du plus long mot est trop lent et les colonnes se refresh une par une très lentement
 +Voir http://​forge.cbp.ens-lyon.fr/​redmine/​issues/​2187
 +
 +== AFC ==
 +
 + - long sans table lexicale ~10 sec
 + - un peu long depuis une table lexicale (2/200) ~1.5 sec
 + -- depuis une table lexicale (1/10000)
 + -- long ~4 sec
 + -- JFC: graphique illsible
 + -- JFC: l'​éditeur de graphique rame
 + -- JFC: javaw.exe utilisent beaucoup de CPU lors du déplacement,​ zoom dans le graphique
 + - le diagramme des Eigenvalues étant un CategoryChart le zoom ne se fait que sur l'axe Y est les labels des axes ne sont pas lisibles si trop de parties\\ -> repasser le diagramme en XYChart pour avoir un zoom du même type que dans les dimensions de partition (sur Y et X)
 + - goulet dans la création de la table lexicale à cause de "​[]"​
 +
 +== CA ==
 +
 + - long sans table lexicale ~11 sec
 + -- un peu long depuis une table lexicale (2/200) ~1.5 sec
 + -- depuis une table lexicale (1/10000)\\ -> semble planter, attendu 10 minutes\\ -> dernier log console : Calcul de la CAH...\\ -> dernier log R eval
 +R safeEval: try({library(FactoMineR)},​ silent=FALSE)
 + ​return:​ FactoMineR, Rserve, stats, graphics, grDevices, utils, datasets, methods, base
 +R safeEval: try({FactoMineRAHC2 <- HCPC(FactoMineRCA657,​ cluster.CA="​columns",​ nb.clust=2, metric="​euclidean",​ method="​ward",​ graph=FALSE)},​ silent=FALSE)\\ -> dernière subtask : Computing children of word 1 / 10000: 2 classes colonnes
 + -- Rterm.exe mange beaucoup de CPU
 + et surtout 1 400 000 K de RAM\\ -> le cancel ne semble rien faire
 + -- même comportement de plantage depuis une AFC (1/10000)
 +
 + ! par ailleurs il reste parfois des .prefs de résultats alors que les résultats ont soit planté (soit été effacés ?)
 +
 +=== Partition ELTECFRAORIG_speaker_n (257 parties) ===
 +
 + - très très long ~2min 20 sec\\ -> javaw.exe utilise beaucoup de CPU
 + - j'ai l'​impression que le temps de création d'une Part dépend du niveau de la balise dans CQP
 + par exemple la requête :
 + ​[_.sp_n="​97"​] expand to sp
 + ​semble mettre plus de temps à répondre que :
 + <​text_booktitle="​Waterloo">​[] expand to text
 + ​est-ce que c'est normal ? Cela vient de CQP ou bien de l'​interfaçage par TXM ?
 + ​est-ce que c'est normal qu'on perdre la trace de la hiérarchie originel ? eg. [text_xxx_xxx_sp_n="​97"​]
 + ​Après tests :
 + 1) dans CQP les 2 requêtes semblent aussi rapides
 + 2) cela ne vient pas du flush() après le compute, en le supprimant cela ne change rien
 + 3) on peut voir dans la vue Progression un "​Building Workspace (sleeping)"​ après chaque requête mais en virant "Build automatically"​ du Workspace, cela ne change rien
 +
 +== Dimensions de partition ==
 +
 ++ RAS niveau des performances
 +
 +== Table lexicale ==
 +
 + - très long ~18 sec
 + - l'UI rame pas mal
 + -- Fmin = 1, Vmax = 10 000
 + -- très long ~20 sec
 +
 +== Index ==
 +
 + + RAS : faire
 + + RAS : [frlemma="​faire"​] | [frlemma="​voir"​]
 +
 +== Spécificités ==
 +
 + - manquent des logs
 +
 + - très long : ~26 sec\\ -> Note dev : la table lexicale créée et en fmin = 1 et fmax = 9999999
 + - Rterm.exe mange beaucoup de CPU
 + - l'UI rame
 + - depuis une table lexicale (2/200), long ~7 sec
 + - depuis une table lexicale (1/10000), long ~7 sec
 + - problème du rafraichissement des colonnes à l'​ouverture de l'​éditeur sous Windows qui peut prendre plusieurs secondes.
 + Le pack des colonnes basé sur la taille du plus long mot est trop lent et les colonnes se refresh une par une très lentement
 + Voir http://​forge.cbp.ens-lyon.fr/​redmine/​issues/​2187
 +
 +== AFC ==
 +
 + - long sans table lexicale ~20 sec
 + - un peu long depuis une table lexicale (2/200) ~2.6 sec
 + -- depuis une table lexicale (1/10000)
 + -- un long ~3 sec
 +
 +=== Sous-corpus ELTECFRAORIG_text_booktitle (de A à F) ===
 +
 + + RAS
 +
 +== Propriétés ==
 +
 + + RAS
 +
 +== Lexique ==
 +
 + - un peu long ~4 sec
 +
 +
  
public/optimisation/test_perf_ergo.txt · Dernière modification: 2019/11/29 13:26 par slh@ens-lyon.fr