J'ai une machine Windows de 8 CPU 3 GHz qui est estimée pour terminer un calcul utilisant Excel en 16 jours basé sur un test de données échantillon. Cette performance n'est pas acceptable(!).
Le calcul n'utilise pas les capacités d'Excel mais est essentiellement un script VBA appelant un objet COM qui a une fonction Calculator.
Le processus Calculator utilise 25% de CPU et Excel utilise 1%. La mémoire d'échange ne semble pas être utilisée. Étant donné que le processus lit et écrit dans des fichiers texte, je suppose que c'est lié à l'E/S. Les comptes de lectures/écritures E/S sont constamment comptabilisés pendant le calcul.
Un vérificateur de virus est installé, mais il ne vérifie pas activement. Par exemple, le CPU est à 0% pendant la période de calcul.
La meilleure suggestion jusqu'à présent est d'utiliser un RAM Disk.
Pouvez-vous suggérer d'autres pistes d'investigation concernant le goulot d'étranglement de performance?
[Plus tard...]
Merci beaucoup pour les conseils ci-dessous. Fondamentalement, le processus Calculator est un calculateur financier spécialisé mais comme mentionné ci-dessous, il semble que le goulot d'étranglement se situe dans son utilisation via COM. Cette méthode supprime toute la fonctionnalité multithread offerte par le calculateur, qui peut également être résolu en tant que service Web.
Le scénario réel impliqué est une mise à jour de table financière tous les trois ans en utilisant ce nouveau Calculator. Malheureusement, pas assez de temps n'a été réservé suffisamment tôt dans le calendrier pour estimer les performances, ce qui a conduit à l'urgence d'enquêter sur le problème de performance. Étant donné que ce calcul n'est pas effectué régulièrement, il n'est pas nécessaire de configurer un environnement optimisé pour la vitesse.
La solution correcte est d'abandonner Excel et d'écrire un répartiteur multithreaded vers le calculateur, mais nous cherchons actuellement un contournement pour obtenir les calculs dans un délai raisonnable.
