Discussion :

[zouriteman]

Etant développeur occasionnel avec DELPHI 5 et DELPHI 7 pour ma famille, je sais que je suis avec un vieil EDI , mais qui fonctionne très bien pour mon usage (sous Win XP) , mais qui me donne des soucis depuis passage sous WINDOWS10-Famille-X64.

La même application , assez simple, compilée avec D5 ou D7, donc 32bits , qui se lancait instantanément sous XP, prend 12 à 23 secondes pour se lancer sous WIN10, et avec des clignotements du curseur sur l'écran.
Dans un article du célébre MARCO CANTU datant de 2018, il incriminait WIN10 CREATOR UPDATE et préconisait de retourner à WIN10 ANNIVERSARY ; le problème viendrait d'un changement radical technique de Microsoft dans la méthode de chargement des DLL (et des BPL)
Le problème aurait été corrigé avec la Build 16215 , mais serait revenu avec la version 1903 (Avril 2019).

Le problème me semble être ailleurs car d'une part je n'utilise pas de DLL ou BPL séparées (tout est dans l' Exécutable) , et j'ai testé l'une de mes applications sur 3 appareils:

* mon PC E7400 avec 2 GIGA et WIN10 v1909 build 18363.720 ===> le problème est là , temps de lancement hyper lent ( 22 sec.) , et en cours d'éxécution des moment très longs d'inactivité , comme si le programme attendait un évènement inconnu.

* un portable ASUS avec 4 giga , WIN10 v1903 build 18362.900 ==> aucun de ces problèmes

* un portable MSI Gamer avec 8 giga , WIN10 v1903 build 18362.959 ==> aucun de ces problèmes

Sur mon PC E7400, l'ayant upgradé avec beaucoup de sueur en Mars 2020 vers WIN10, je ne peux pas rétrograder facilement à la V1903 (qui n'est pas dans l'historique des points de restauration) , si tant est que je puisse actuellement la télécharger quelque part.
je ne peux pas non plus augmenter la mémoire ( PC de 2011 avec des DDR2 )

Ce qui est troublant , c'est que ce phénomène de démarrage hyper lent n'apparait que pour des programmes avec de nombreuses fenêtres ( crées dans le DPR via Application.CreateForm(TFXX , FXX) ) , mais pas du tout pour de petites applications n'ayant que une ou deux fenetres. J'ai tenté de déplacer plus loin quelques CreateForm() , mais le résultat n'est pas probant.

Surtout, ce n'est pas un problème de disque dur, les 3 appareils ont tous un SSD système C:/ WIN10 ( 128 ou 240 giga). Ni de consommation de mémoire par l'application (sous Gestionnaire de Taches , elle prend 10 mo au démarrage, et au pire 60 mo au maximum d'activité)
j'en suis donc réduit à deux hypothèses:
* devoir acheter un nouveau PC pour avoir 4 ou 8 giga DDR3 (sans compter certains périphériques : ma vieille laser HP increvable elle, motif port // !)
* incriminer cette foutu V1909 de Microsoft, en priant pour que la prochaine V2004 ne soit pas pire (Windows Update oblige , difficile d'y échapper)

Quelqu'un a -t-il eu ce type de problèmes , et s'il l'a résolu, merci de me donner la formule magique. Ou bien un spécialiste ets-il certain des causes et de la solution ? MERCI a tous......

[anapurna]

salut

un antivirus peut être ?

[ShaiLeTroll]

des programmes avec de nombreuses fenêtres ( crées dans le DPR via Application.CreateForm(TFXX , FXX) )

En général, dans le DPR, on crée juste la MainForm, éventuellement un MainModule, ensuite tout doit être créé à la volée lorsque cela est utile, principe classique d'un Lazy Loading

Nous avions eu la surprise d'un mode économie d'énergie sur un ordinateur desktop, les performances étaient très faible.

[fbalien]

Bonjour

les 2Go de ram me semble être une des causes possibles de votre problème
le PC doit "swapper" pas mal

[Paul TOTH]

Bonjour

les 2Go de ram me semble être une des causes possibles de votre problème
le PC doit "swapper" pas mal

oui mais à condition que l'appli Delphi charge de grandes quantités de données en mémoire (des bitmaps partout dans toutes les fiches ?)

que donne la courbe d'occupation mémoire lors du lancement de l'appli ?

[zouriteman]

merci de vos commentaires , je répond d'abord à P. TOTH , la réponse étant très facile :
Mémoire consommée restant pratiquement inchangée , 60% d'après le Gestionnaire de Taches de Windows, aucun pic d'ailleurs qui permette de repérer facilement le lancement d el'application. Image ci jointe .

[Paul TOTH]

ce n'est donc pas un pb d'occupation mémoire

si c'est le chargement des DLL qui est en cause, Macro indique

A second workaround (for end users) is to consider one of the tools that fix-up and cleanup PE executables, including reorganizing the import/export tables. There are many such tools. One of them is http://www.ntcore.com/exsuite.php.

est-ce que tu aurais une table d'importation douteuse dans ton exe ?

[zouriteman]

maintenant , pour répondre a The Troll :
pour l'une des appli, j'avais déja appliqué ton principe :
dans le DPR , une seule création
application.initialize
application.title := ........
APPLICATION.CREATEFORM(TPrincipal , FPrincipal)
Application.run

en déportant ailleurs les 3 autres créations de Forms.

Comme je l'ai dit, effet peu probant , le temps de lancement reste vers 12 secondes.

Et cela est sur un PC de BUREAU , donc aucune option spéciale d'économie de batterie...

Et je le répète , sur mes 2 autres appareils (des portables de moyenne game : prix entre 400 et 800€) , le problème n' existe pas , le lancement est immédiat , et il n'y a que deux différences majeures : la VERSION de Win10 , et la taille mémoire ( ceci pour le cas ou l'algorithme de Microsoft pour gérer la mémoire et les appels systèmes changerait radicalement entre une taille modeste et une grande capacité mémoire : mais ou cela est - il documenté ? )

Pour une autre application (dont celle ci-dessus est une version simplifiée) , ayant 19 FORMS toutes créées dans le DPR, le temps de lancement est de 22 secondes, alors qu'il était quasi-nul sous WinXP , et presque nul sur les 2 portables (moins de 2 secondes).

[Paul TOTH]

coupe ton antivirus et ton firewall le temps d'un lancement...j'ai tellement souvent perdu du temps à chercher une explication ailleurs que c'est maintenant ce que je fais systématiquement pour commencer.

[zouriteman]

ce n'est donc pas un pb d'occupation mémoire

si c'est le chargement des DLL qui est en cause, Macro indique



est-ce que tu aurais une table d'importation douteuse dans ton exe ?

****************

Alors là, je ne suis assez expert pour savoir ce que c'est , et ou et comment trouver cette table d'importation.
S'il y a un tuto quelque part, merci de me donner le lien.

[zouriteman]

coupe ton antivirus et ton firewall le temps d'un lancement...j'ai tellement souvent perdu du temps à chercher une explication ailleurs que c'est maintenant ce que je fais systématiquement pour commencer.

sur les 3 appareils , j'a le même antivirus , à savoir AVG FREE ,
mais je vais faire le test que tu me demandes.....

***** voila c'est fait ****
AVG désactivé pour tous ses "agents"
de plus, AVG dispose d'une liste blanche d'applications à ne pas tester , j'y ai rajouté les 2 applis (les .EXE )

résultat inchangé : les temps de lancement restent à 12 et 22 secondes.

********************

[zouriteman]

ensuite , désactivation du Parefeu , celui standard de Win10, BitDefendeur je crois , via parametres -> securité ; désactivation des 3 réseaux public , privés , domaine.

Résultats quasi identiques , je constate vaguement une très légère amélioration : 11s au lieu de 12s , 20s au lieu de 22s.

merci de vos réponses
**********************

[ShaiLeTroll]

Même si cela ralentira peut-être encore plus, il faut ajouter un log en fichier, pour trouver la section de code lente, un travail de fourmi mais il faut bien chercher quelque part
Au début faudra mesurer avec GetTickCount voire QueryPerformanceCounter chaque ligne de code du DPR ...

Si le temps est lent avant même l'apparition du fichier, c'est donc le chargement de l'exe qui est long
Un programme Delphi utilise beaucoup de DLL Windows, vous pouvez les lister sur votre ordinateur doté d'un Delphi, rien que les compter et voir si il y a bcp de chargement/déchargement, il faudrait voir comme débugger votre EXE à distance, voir si vous pouvez récupérer cette trace
(La procédure D7 est peut-être différente de l'actuelle, faudra chercher dans les HLP)

Sinon, l'option d'économie d'énergie, justement, j'ai mis du temps à la trouver car c'était aussi sur une station de bureau, ce qui n'avait donc aucun sens que cela soit activé, avant on avait coupé AntiVirus et Services, quelle perte de temps !
Cela avait un sacré impact sur le JavaScript, je voyais les pages se construirent par bout, c'est grâce à des mesures de temps en Delphi qui j'ai découvert l'anomalie.

De plus, vos 2Go, il y a une compression de la mémoire activée selon votre image du gestionnaire de mémoire, même mon Win8 avec juste deux WebBrowser et deux Words, j'en suis à 4Go de consommé, comment Win10 tourne sur une si petite machine, 2Go semble que cela soit le minimal autorisé en 64 bits

[Paul TOTH]

alors que je fais pour ça (notamment pour débuguer sur un poste utilisateur) c'est d'ajouter ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
program Projet1;
{$DEFINE TRACE}
 
uses
  Winapi.Windows, ...
 
begin
{$IFDEF TRACE}
  AllocConsole; // dans Winapi.Windows
{$ENDIF}
{$IFDEF TRACE}WriteLn('Application.Initialize');{$ENDIF}
  Application.Initialize;
{$IFDEF TRACE}WriteLn('Instantiation de Form1');{$ENDIF}
  Application.CreateForm(Form1, TForm1);
{$IFDEF TRACE}WriteLn('Application.Run');{$ENDIF}
  Application.Run,
end;

ça t'ouvre une fenêtre console qui log tout ce qu'il se passe...et tu peux mettre cela un peu partout dans ton code pour identifier la portion de code qui est lente.

[zouriteman]

merci des 2 derniers messages que j' utiliserais dans l'avenir pour mieux analyser les choses.
mais ayant voulu tester avec 4 giga de ram, j'ai bouzillé ma carte mère à cause d'une DDR2 de récupération foireuse.
D'ou seule solution, budget 300€ pour achat en urgence d'une CM + intel 9100F + DDR4 8go + ventil.
Tout le reste inchangé, en particulier mêmes Disques durs, même SSD avec WIN10 , lequel WIN10 a démarré sans broncher ni messages particuliers.

Et miracle, mes applications DELPHI démarrent instantanément , comme autrefois sous WinXP !

Conclusion évidente : Microsoft a deux algorithmes différents pour charger une application Delphi (et/ou allouer la mémoire) , en fonction de la taille de Ram :
* une méthode stupide pour une taille de 2 giga ( ou moins ) , qui générère un énorme délai de lancement ; je dis stupide car , dans mon cas , quand j'ai au moins 800 Mo de mémoire totalement libre sur les 2go physiques , pour lancer une appli qui demande au pire 10 à 20 Mo , pour quoi faire compliqué et lent ?
* une méthode bien meilleure dès 4 et 8 Go de Ram

et je n'ose imaginer la galère de ceux qui suivent la spécif technique qui dit qu'il suffit de UN giga de mémoire pour WIN10 , certes pour x32 , je découvre que j'étais au minimum requis de 2 Giga en x64 !

Je vous laisse installer une barrette de 2 go à la place de vos 8 ou 16go pour vérifier l'effet sur vos propres applications.

Salut aux trois éminents experts du forum.

[ALWEBER]

Quelques informations complémentaires sur le sujet :
https://www.malekal.com/optimisation...-windows-swap/

[zouriteman]

je viens de découvrir l' outil TASKLIST , commande TaskList /FO CSV > maliste.csv , qui après récupération sous EXCEL ou équivalent (j' utilise LIBRE OFFICE donc SCALC) et petit travail de mise en forme , permet d'analyser finement la consommation mémoire.
Et là c'est la surprise :
Mon navigateur OPERA, avec seulement 2 fenetres ouvertes , consomme 1,63 Giga !
Mon anti virus AVG consomme 347 Mo
mon client Messagerie (Eudora) et LIBRE-OFFICE (seulement SCALC ouvert) sont raisonnables : 92 et 96 Mo

Tout ce qui est non identifaible et qui semble être le "SYSTEME WINDOWS 10 " consomme la quantité incroyable de 2,57 Giga , dont une myriade de SVCHOST et de RUNTIME BROCKER , et le File-Explorer pour 187 Mo (pour 1 seule fenetre)

le pire étant ce que microsoft m'impose et dont j'aimerais me débarrasser , soit pour non utilisation, soit utilisation très rare :
* OneDrive = 55 Mo ( j'utilse mon cloud payant et plus sur PCloud )
* Skype = 229 Mo
* et probablement plusieurs autres services ......

et à coté de tout cela, ma petite application , sujet de cette discussion, ne consomme que 16 Mo ... Une misère !!!

et au total 5,2 Giga ...... C'est l'inflation !!

[Galet]

Merci Zouriteman pour le partage de cet outil...