Lenteur code vba sur Windows 10

Bonjour.

J'ai développé une application vba distribuée sous forme de Macro complémentaire (xlam) sur Excel, son l'objet est la réalisation de devis complexes. Cette application qui fait 100'000 lignes de code vba tourne depuis plusieurs années, elle a donc été utilisée tout d'abord sur Excel 2003 pour sur toutes les versions intermédiaires jusqu'à Excel 2016. Dans cette application une commande est particulièrement gourmande en temps et j'observe que cette même commande est bien plus lente sur Windows10 que sur Seven Ultimate étant entendu qu'elle tourne sur Office 2016. J'ai donc créé pour l'occasion un fichier devis type et ai affiché les temps de traitement. Pour ce fichier type je constate 24 sec de traitement sur une machine Seven équipée d'Office 365 version 2016. Le temps de traitement sur une machine Windows10 et la même config Office passe à 40 sec !!! Les deux machines disposent de plus de 8 GBytes de mémoire vive et sont tout à fait comparables quant à leur puissance. J'ai aussi fait le test sur une machine virtuelle HyperV // Seven // Office 2016 et je tourne également en 24, 25 secondes. Le fait qu'Outlook soit démarré ou pas impacte ce temps de traitement de façon sensible et cela de façon plus importante sur la machine Windows10 que sur la machine Seven.

Que pouvez-vous me dire sur cette constatation ?
Avez-vous constaté une telle dérive sur Windows10 et si oui comment y avez-vous remédié ?
Comment redonner de la puissance à Excel en environnement Windows10 ?
Autre ?

Vos suggestions, analyses seront les bienvenues
En vous remerciant par avance - Alain

Bonjour,

Citation:

---

Dans cette application une commande est particulièrement gourmande en temps

---

quelle commande, cette portion de code (et un peu plus pour avoir le contexte) serait un minimum, avec l'explication qui va avec

Désolé mais derrière la commande dont je parle, commande propre à l'application et qui est en charge de la vérification/normalisation du devis il y a quelques milliers de lignes vba et il ne m'est donc pas vraiment possible d'en donner le détail. Je vais tout de même essayer de clarifier le genre d'opérations réalisées. Pour commencer ce code ne fait aucune sélection de cellule, si c'était le cas il ne serait tout simplement pas viable... Ce code enregistre en mémoire toutes les lignes d'un devis (situé dans une feuille de calcul) puis parcours plusieurs fois cette mémoire pour opérer principalement différentes opérations de vérification, il
- vérifie les formules de calcul et les corrige lorsque nécessaire (très rare),
- contrôle le niveau de retrait (outline) de chaque ligne en fonction de son positionnement dans des chapitres,
- force le format de chaque ligne en fonction de son type,
- assure la création/mise à jour d'une table de données alimentée par les éléments du devis, table qui alimente elle même plusieurs tableau croisés d'analyse,
- assure la création d'un fichier XML puis son enregistrement,
- vérifie plusieurs fois l’existence de répertoires et de fichiers (souvent à l'aide du 'fso')
- etc.

La plupart des fois ce code ne rentre aucune données ou formule sur la feuille de calcul, il se cantonne de faire de la vérification, la seule action que je suis obligé de forcer sur la feuille de calcul et qui je sais est gourmande en temps, c'est d'appliquer un format de ligne à chaque ligne. Il est à noter tout de même que
- ce code comte sur le recalcul effectué par Excel et que donc ce dernier n'est pas inhibé,
- que certaines formules du devis sont des formules matricielles, celle que l'on obtient en faisant < Shift Ctrl Enter > et qui sont entourées de { ... } dans la barre de formule.

Mais à mon sens, et je peux bien sur me tromper, la question n'est pas tant ce que fait le code en question mais plutôt le fait qu'il ne tourne vraiment pas à la même vitesse en fonction de l'Operating System ou il évolue. A moins bien sur que je ne touche à une ou plusieurs fonctionnalités moins bien supportée par Excel 2016 mais si c'est le cas comment les identifier ?

J'ai aussi comparé Excel 2016 avec Excel 2010 et cela sur la même machine Seven et la il y a aussi des différences mais bien moins importantes, 24 sec sur Excel 2016 pour 22 sec sur Excel 2010. Je me sens du coup avec l'arrivée de Windows 10 otage d'un nouvel environnement qui ralenti mon application sans que je n'en comprenne la ou les raisons... :(

Alain

Windows 10 demande plus de mémoire et Excel 2016 aussi. Su tu as décidé que ce n'est pas la faute de ton code, on n'y peut rien. Mais Excel a toujours besoin de tous ses classeurs ouverts d'être toujours en mémoire vive et au complet. Ton ralentissement peut être dû juste à un manque de mémoire. D'autant plus que ton laïus débite à peu près juste des opérations qui bouffent énormément de mémoire.

Comment veux-tu que l'on te donne une réponse, si tu ne montres rien. :cristal:


Je vais continuer de prêcher dans le désert et dire que tu devrais utiliser VB.net ou C# et remplacer ta macro par une dll compilée.

Aspect mémoire : J'ai 32 GBytes sur la machine Seven qui fait tourner le code concerné en 24 sec et 24 GBytes sur la machine Windows 10 pro qui elle fait tourner le même code en 40 secondes il est donc fort peu probable que le problème vienne de la mémoire.

Excel 2016 : 24 sec avec Excel 2016 sur Seven et 40 sec avec Excel 2016 sur Windows 10 - pour moi Excel 2016 n'est pas le coupable ou alors c'est le cocktail Excel 2016 + Windows 10 qui ne tourne pas rond.

Utilisation d'un autre langage : oui j'y ai forcément pensé mais cela ne peut pas se faire en un claquement de doigt, loin de la et puis cela obligerait à reprendre de zéro une application complexe bien débuggée, j'estime la tache à environ 1 homme/an sans parler du temps de formation aussi vous comprendrez qu'il y a de quoi hésiter et cela même si on est convaincu du bien fondé de l'entreprise.

Je reste pour le moment sur ma première motivation qui est de tenter de comprendre ce qui ne tourne pas rond dans Windows 10 avec mon code vba. Mon propre code porte certainement une responsabilité, pas trop de doute sur le sujet mais tout de même, multiplier par deux un temps de traitement en passant de Seven à Windows 10 y'a de quoi penser ferme qu'on est pas le seul coupable, non !

Alain

Bonjour
La mémoire virtuelle de base n'est pas la seule à considérer
Sont également à considérer :
- la mémoire disponible avant démarrage du classeur
- Windows n'a jamais su gérer parfaitement la mémoire, notamment si utilisation du fichier de pagination. A ce propos : ce fichier a-t-il été configuré identiquement sur les deux machines ?
- les accès disques, eux-mêmes gênés par la fragmentation éventuelle
- le nombre de "coeurs". En rappelant que les formules de calcul de Excel sont traités dans un fil distinct de celui de VBA. Excel pourrait (si option Excel dans "options avancées") traiter le fil "formules" dans un coeur également distinct
- le travail des récupérations automatiques (si telle option a été choisie)
etc ...