Bonjour,
 
Dans le cadre de notre projet développé en Visual Basic 6 (SP5), nous avons constanté des problèmes de performances sous Windows NT 4 qui ne se produisaient pas sous d'autres OS.
Suite à la découverte de ce problème nous avons procédé à des tests. Le code ci-dessous a été exécuté sur la même machine et sur chacun des systèmes d'exploitation suivants : Windows 98 SE, Windows NT 4 SP6, Windows 2000 Server SP 4 et Windows XP SP1.
Les performances sont très dégradées sous Windows NT. Sur les autres OS, elles sont à peu prêts acceptables  et équivalentes :
- Sous Windows NT, la "msgbox" affiche 26 secondes !
- Sous tous les autres OS, le temps est d'une seconde environ.
Nous avons ensuite testé le code ci-dessous en utilisant des tableaux à la place des collections, le constat est le même : performances exécrables sous Windows NT 4.
Je voudrais savoir s'il y a une cause connue à ce problème sous NT et si éventuellement il existe une solution pour y remédier
 
Merci d'avance pour vos réponses
 

franchement, j'ai pas d'idée, et j'ai pas encore vu un truc qui ressemble à ça sous google

Mêmes versions de tous les ocx et autres machins?

t'as jamais rencontré ce genre de pb ? parce que l'écart entre NT et les autres windows est quand même impressionnant

bin j'ai bossé un certain temps en VB6 sous NT mais c'était il y a 4 ans, donc pas les mêmes versions que tu utilises
 
J'ai franchement rien vu de ce genre

Comme tu peux le voir dans le code, on n'utilise aucun OCX, juste les fonctions VB de base. on installe ça sur une config vierge via un package fait avec l'assistant empaquetage et déploiment.
 
 
P.S. ça ne vient pas d'une install spécifique de Windows NT puisque ce problème nous a été remonté par des clients qui tournaient sous NT et qui rencontraient des problèmes de lenteur assez invivables.

Le problème c'est que ça passe assez inaperçu tant qu'on ne fait pas de bench ou qu'on ne tombe pas sur ce cas précis (charger un grand nombre d'objets et les stocker dans une collection/tableau) dans son code.

au fait, vous chargez autant d'objets en mémoire? c'est bien nécessaire?
 
Sinon j'ai pensé à un bug d'allocation mémoire comme il y en avait un sur le SP1 de Windows XP (corrigé depuis) et que j'ai vu en action sur un tabletpc qu'on m'avait prêté et c'était très très très lent alors que je n'allouais qu'une centaine de contrôles au maximum

non, on fait ça pour le plaisir
Evidemment que c'est nécessaire banane, le prblème serait réglé si ce n'était pas le cas.
 

C'est une piste, faudrait qu'on teste avec d'autres service pack

bin cent mille objets quoi, ton appli en production place cent mille objets en mémoire? Je me suis fait tanner quand j'ai raconté ça à quelques programmeurs VB de ma boîte

C'est un cas extrème, mais on reste dans cet ordre d'idée (plusieurs dizaines de milliers d'objets)

A votre place, je bosserais là-dessus: je connais pas le business, mais faire gérer autant d'objets par VB en mémoire, c'est du pur suicide ou je ne m'y connais pas

On NE PEUT PAS faire autrement. et d'ailleurs sous 2000, XP ou 98 ça ne pose pas vraiment de problèmes (à part un certain temps d'attente à la fermeture du programme).
 
EDIT: si tu veux que je t'explique le problème plus en profondeur->PM

ok

UP

j'attends toujours ton MP au fait