Khiops launches very slowly on Windows, e-buro

marcboulle commented 3 months ago

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

marcboulle commented 2 months ago

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)

lucaurelien commented 2 months ago

Je contacte la DSI pour la partie eburo

marcboulle commented 2 months ago

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

marcboulle commented 2 weeks ago

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

marcboulle commented 2 weeks ago

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

lucaurelien commented 2 weeks ago

Pour ma part, je trouve la Solution 2 (passer à un look and feel "metal") satisfaisante.

marcboulle commented 2 weeks ago

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.

KhiopsML / khiops