KhiopsML
Khiops launches very slowly on Windows, e-buro
Description
When you click on the Khiops icon, Khiops launches very slowly on Windows, e-buro. It takes between 10 and 20 seconds (some times almost one minute) before seeing the application window.
Questions/Ideas
- when Khiops is run "as administrator", it takes less than one second
- the Orange anti-virus may be the problem
- A potential solution
- ask Orange IT to put Khiops in a white list
- ask Orange IT to add Khiops in list of default applications in the "Centre logiciel"
Context
- Khiops version: 10.2.2
- OS description (use
khiops -s): Windows, e-buro
A tester dans les trois cas d'installation:
- program files
- my program files
- applications
A tester: en mode batch et GUI
A tester: Khiops et Khiops coclustering (sans MPI)
Protocole de test
Test d'installation Windows, avec la dernière version de l'installeur (khiops-10.2.2-setup.exe) disponible sur le site On désinstalle préalablement l'outil existant.
Tests depuis un shell dos, répétés plusieurs fois pour estimer la variation du temps:
- mode batch: khiops (resp khiops_coclustering) avec option -v ou -h
- mode GUI: khiops (resp khiops_coclustering) sans option, identique au double-clic sur l'icone de l'outil sur le desktop
Puis test additionnel avec un scénario d'apprentissage.
Résultats
Résultats identiques quel que soit le répertoire d'installation
- C:\Program Files: résultats identiques à ceux de C:\My Program Files
- C:\Applications: idem
Pas d'impact du toolkit java, testé avec
- le jre temurin vendoré avec Khiops
- le jre installé avec le Centre Logiciel dans
C:\Program Files - un jdk installé dans
C:\Program Files
Résultats détaillés, en lancement normal
- mode batch
- khiops: ~2 s (+-1 s)
- khiops_coclustering: 0 s
- mode GUI
- khiops: ~15 s (grande variance, de 10 s à plus de 40 s)
- khiops_coclustering: ~15 s (grande variance, de 10 s à plus de 40 s)
Résultats détaillés, en lancement en tant qu'administrateur
- mode batch
- khiops: ~2 s (+-1 s)
- khiops_coclustering: 0 s
- mode GUI
- khiops: ~7 s (+- 2 s)
- khiops_coclustering: ~1s
Attention: en mode admin, on se retrouve initialement dans le répertoire C:\Windows\Systeme32, et non dans le répertoire attendu C:\users\public\khiops_data, ce qui rend l'accès aux exemple très pénible
Test additionnels en mode batch avec scenario
Scenario d'apprentissage sur la base adult, sans les arbres Utilisation du scenario en mode batch: -i ... -e ... -b
ClassManagement.OpenFile // Open...
ClassFileName C:\Users\Public\khiops_data\samples\Adult\Adult.kdic // Dictionary file
OK // Open
TrainDatabase.DatabaseFiles.List.Key Adult // List item selection
TrainDatabase.DatabaseFiles.DataTableName C:\Users\Public\khiops_data\samples\Adult\Adult.txt // Data table file
AnalysisSpec.TargetAttributeName class // Target variable
AnalysisResults.ResultFilesDirectory Test // Result files directory
AnalysisSpec.PredictorsSpec.ConstructionSpec.MaxTreeNumber 0 // Max number of trees
ComputeStats // Train model
Exit // Close
OK // Yes
Résultats: overhead sur le temps global d'exécution, de plus de 5 s en mode user, vs le mode admin
Test selon le nombres de processeurs
Paramétrage préalable par set KHIOPS_PROC_NUMBER=1,... Temps recueillis dans le log: cumul du Data preparation time et du SNB train time
Résultats de références sur la même machine, dans mon environnement de développement:
- ~1 s (+- 0.5 s) s selon le nombre de coeurs, de 1 à 20
- même résultats en lançant le MODL.exe installé depuis le kht_test de l'environnement de développement
- que les données soient dans C:\Users\Public\khiops_data ou ailleurs
Résultats obtenus depuis un shell en mode admin, depuis C:\Applications\khiops\bin, avec la commande khiops.cmd -i scenarioTrain._kh -e log.txt
- 1 core (on n'utilise pas MPI): ~1 s
- 4 cores: ~ 2 s
- 20 cores: ~6 s
- très forte dégradation des performances, avec forte variance
Synthèse
Impact répertoire d'installation: aucun Impact MPI: significatif, de 2 à 5 s, même en mode admin Impact mode admin vs user: énorme, on passe d'utilisable à non utilisable
Performances très dégradées avec le nombre de coeurs
- mauvaise expérience utilisateur
Actions
Résolution du problème de performance dégradée avec le nombre de coeurs
Explication trouvée en comparant khiops_env et kht_test
Solution: dans khiops_env, lancer mpi avec la commande
set KHIOPS_MPI_COMMAND="%MSMPI_BIN%mpiexec" -n %KHIOPS_PROC_NUMBER%
au lieu de
set KHIOPS_MPI_COMMAND="%MSMPI_BIN%mpiexec" -al spr:P -n %KHIOPS_PROC_NUMBER% /priority 1
On retrouve les performances attendues
La correction sera prise en compte avec la pull request en cours https://github.com/KhiopsML/khiops/pull/343
Problème du lancement en mode admin
Problèmes potentiels à investiguer
- paramétrage de l'antivirus
- paramétrage du firewall (les forums le recommandent, mais la config e-buro ne le permet pas)
- ...
Bilan d'analyse et tests sur l'impact de l'antivirus MDE (Microsoft Defender for Endpoint)
- L’outil d’analyse MDEClientAnalyser a été lancé pour récupérer les logs MDE pendant la phase de test.
- Les tests qui ont été effectués sont les suivants :
- 1 exécution en contexte admin, 3 secondes pour ouvrir l’application.
- 2 exécutions en contexte utilisateurs, 20 secondes pour ouvrir l’application.
- 1 exécution en contexte utilisateur sur mon poste sans MDE, 3 secondes.
- 1 exécution en contexte utilisateur sur un poste équivalent avec MDE, 3 secondes.
- L’analyse des logs et de la console MDE n’a pas remonté de comportements anormaux.
- Des tests supplémentaires ont été effectués sur d’autres postes équivalents, et ont montré que ce problème n'est pas présent sur d’autre machines.
- L’hypothèse MDE est à écarter dans l’attente des prochains tests, car le logiciel fonctionne bien avec MDE sur un poste équivalent
- Le problème vient du poste spécifique utilisé pour les tests
Identication d'un problème Java avec les FileChooser
L'hypothèse de l'antivirus ayant été écartée, le code a été instrumenté pour identifier à quel moment on perd une vingtaine de secondes lors de l'ouverture de l'application GUI en mode utilisateur.
Le résultat est que tout le temps passé provient d'une unique unique instruction java dans GUIFileDirectoryChooser:
private static JFileChooser globalFileChooser = new JFileChooser();
Il s'agit de la première instanciation d'un FileChooser dans la GUI, qui prend un temps très long. Ce problème est apparemment connu: https://stackoverflow.com/questions/49792375/jfilechooser-is-very-slow-when-using-windows-look-and-feel https://forums.oracle.com/ords/apexds/post/jfilechooser-incredibly-slow-both-to-initialize-and-to-chan-0912 https://bugs.openjdk.org/browse/JDK-6372808
En fait, le FileChooser avec le loook and feel Windows commence par scanner l'ensemble de tous les drives de la machine pour dimensionner la fenêtre du FileChooser. En cas de drives réseaux dont l'accès peut être très lent, cela peut entrainer un temps d'attente considérable. Et effectivement, sur mon poste développeur, plusieurs drives réseaux sont utilisés (montés en mode administrateur), ce qui n'est pas le cas sur la plupart des postes bureautiques.
Solution potentielles
Solution 1: préchargement d'un FileChooser
- au lancement de l'application, lancer la création d'un FileChooser dans un threads
- un peu complexe
- ne résout pas le problème d'un utilisateur ouvrant très rapidement un FileChooser, ce qui est un cas d'usage fréquent
Solution 2: passer à un look and feel "metal" (cf. Illustration ci-dessous)
- techniquement, on passe de
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());àUIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName()); - actuellement, le look and feel est celui de la plateforme en cours (windows, linux...)
- le look and feel "metal est un look and feel cross-plateforme unique
- avantage; très rapide
- inconvénient: on n'a plus le look and feel de la plateforme courante, notamment sous Windows
Solution 3: passer à un look and feel "metal" uniquement pour le FileChooser sous Windows
- avantage; très rapide, et sans changement de look and feel presque partout
- inconvénient: sous Windows, non-homogénéité du look and feel localement au FileChooser
Solution 4: garder l'ergonomie Windows, aevc un FileChooser bridé n'ayant pas préalablement scanné les drives réseaux
- techniquement, on passe de
private static JFileChooser globalFileChooser = new JFileChooser();à
private static JFileChooser globalFileChooser = new JFileChooser() {
public void updateUI() {
putClientProperty("FileChooser.useShellFolder", Boolean.FALSE);
super.updateUI();
}
};
- avantage: très rapide, on garde le même look and feel que maintenant, partout
- inconvénient: le FileChooser s'ouvre dans boîte de dialogue plus rudimentaire (cf. ci-dessous)
- en cas de drive réseau, il faut un clic ou deux pour les retrouver
- et on paie alors le temps de scan des drives réseaux la première fois
- et ça peut a nouveau être long quand on explore le contenu de nouveaux drives réseaux
Illustration
Look and Feel Metal
Look and Feel Windows
Look and Feel Windows, sans le scan des drives réseaux
Pour ma part, je trouve la Solution 2 (passer à un look and feel "metal") satisfaisante.
On part sur la solution 2, meilleurs compromis entre ergonomie et rapidité dans les cas d'usage. Et même look and feel sur toutes les plateformes.