plateforme txm - #task 2675 · - dimensions de partition + ras niveau des performances - table...

Plateforme TXM - Task # 2675

Status: New Priority: Normal

Author: Sebastien Jacquot Category: Diagnostic and optimization

Created: 11/27/2019 Assignee:

Updated: 02/14/2020 Due date:

Subject: Diagnose TXM behaviors processing a large corpora

Description

Diagnose TXM behaviors processing a large corpora

SJ: WIP, premiers retours

===== Tests performance et ergonomie gros corpus =====

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 CAH)

- 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

- L'UI des éditeurs reste accessible lors des calculs long ce qui peut provoquer des bugs sur certaines commandes (voir ticket:

#2747)

01/16/2021 1/5

- 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

- 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

01/16/2021 2/5

- 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

- 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


- 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 "[]"

- CAH


-- un peu long depuis une table lexicale (2/200) ~1.5 sec


=> 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}, 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

01/16/2021 3/5

http://forge.cbp.ens-lyon.fr/redmine/issues/2673


=> 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



- 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


- un peu long depuis une table lexicale (2/200) ~2.6 sec


-- un long ~3 sec

01/16/2021 4/5


- Sous-corpus ELTECFRAORIG_text_booktitle (de A à F)

+ RAS

- Propriétés

+ RAS

- Lexique

- un peu long ~4 sec

History

#1 - 11/27/2019 05:04 pm - Sebastien Jacquot

- Description updated

#2 - 11/28/2019 09:20 am - Sebastien Jacquot


#3 - 11/29/2019 09:56 am - Sebastien Jacquot






01/16/2021 5/5

plateforme txm - #task 2675 · - dimensions de partition + ras niveau des performances - table...

Documents