2009-05-28 8 views
5

Nous avons beaucoup de rapports qui sont générés via VBA & Excel. Seul un faible pourcentage des rapports sont des calculs réels - la majorité du travail est des appels sql et le formatage/écriture de cellules. La plus longue prend plusieurs heures, la majorité prend environ 20-30 minutes chacun. Le code VBA/Excel se branche dans une DLL que les applications de bureau VB6 utilisent - c'est ici que tous les appels sql sont faits. Bien que je sois sûr qu'il y a place à amélioration ici, ce n'est pas ce qui me préoccupe - les applications de bureau sont assez vives.Profileur VB6/VBA gratuit et meilleures pratiques Excel

Deux fonctions VBA sont utilisées en abondance: elles sont appelées GetRange et SetupCell et elles apparaissent presque toujours ensemble. La fonction GetRange est un wrapper pour l'objet Excel.Range. Il prend une feuille, et 4 valeurs pour les étendues de la gamme. Son utilisation principale est de choisir la cellule pour l'édition. Il ne semble pas y avoir beaucoup de chance de l'optimiser, mais est-ce le meilleur moyen?

Son partenaire est SetupCell. Cela prend un objet Excel.Range, du texte et une douzaine de paramètres sur la cellule (police, bordures, etc.). La plupart de ces paramètres sont des booléens optionnels mais encore une fois, cela semble très inutile. Certains d'entre eux peuvent être posthumes, mais certains dépendent des valeurs contenues dans la cellule.

Il y a beaucoup de code contenu dans ces fonctions, principalement si les instructions et le travail ne m'apprécient pas de le poster.

Je suppose que j'ai deux questions: Y at-il une meilleure façon et quel est il et est il y a profileur gratuit que je peux utiliser pour voir si la majeure partie du temps est ici ou dans le dll?

Répondre

3

Avez-vous pensé à utiliser une solution de reporting? Quel est votre backend db? Si vous utilisez MSSQL 2000 ou version ultérieure, vous pouvez utiliser une solution de reporting assez décente que vous pouvez utiliser gratuitement. SQL Server Reporting Services.

Il semble que les rapports passent la majeure partie de leur temps à formater des cellules. Cela pourrait expliquer pourquoi les rapports semblent si lents et l'application de bureau ne le fait pas. Alternativement, si vous connaissez le formatage à la main et qu'il est assez statique, vous pouvez pré-formater les feuilles pour réduire le travail.

Je vais jeter cela là aussi. La plupart des solutions de reporting permettent une mise en forme conditionnelle et autres, mais comme elles sont conçues pour fonctionner, ces performances seront bien meilleures qu'Excel.

+0

Pas si facile. Les rapports doivent être de longueurs différentes, certaines des cellules doivent être colorées en fonction de la valeur dans les cellules (ou une somme des cellules). –

+0

SSRS sera en mesure de faire face à presque tout ce que vous lui lancez - je seconde cette réponse. –

3

Ceci n'est pas une recommandation du profileur, mais une suggestion pour accélérer les macros Excel qui passent leur temps à mettre à jour l'écran. J'ai eu d'excellents résultats en désactivant la mise à jour de l'écran pendant l'exécution de la macro: set Application.ScreenUpdating = False, et also using a number of other similar settings. Assurez-vous de les réactiver lorsque la macro se termine: P

+0

Nous l'avons déjà fait et nous avons défini Application.Calculation sur manual (xlCalculationManual). –

1

Ce n'est pas gratuit mais vous pouvez le profiler avec ceci. Je soupçonne que la démo sera adéquate à vos besoins: http://www.aivosto.com/vbwatch.html

+0

Pour certains rapports, oui. Pour les autres, non. Pour chaque feuille de calcul, nous avons un 'fichier' vba, plus plusieurs 'fichiers' de support. Il ne fonctionnera certainement pas sur la DLL car il a plus de 100 classes et modules. –

6

plusieurs heures est ridicule pour un rapport. Si le problème est VBA acheter "Professional Excel Development" (Stephen Bullen, Rob Bovey et al): il a un profileur VBA gratuit appelé PerfMon.

Si le problème est calcul Excel voir http://msdn.microsoft.com/en-us/library/aa730921.aspx?ppud=4

Mais je pense que le problème est la surcharge élevée associée à référençant cellule par cellule choses: vous devez toujours travailler dans les grands blocs de cellules à la fois.

+0

Beau pimpage pour vous :-) Sérieusement bien que le problème ne soit pas avec le calcul - nous faisons très peu de calcul (excellent ou pas). Un profileur aiderait à déterminer si les appels à la base de données sont en train de tuer le système ou si le formatage lent cellule par cellule le détruit. Comment pouvez-vous travailler avec un gros bloc de cellules à la fois? –

+2

Si vous ne voulez pas utiliser PerfMon de Stephen Bullen alors pourquoi ne pas simplement ajouter un code temporel en utilisant le minuteur Windows à haute résolution? faire des choses en blocs: l'approche de base consiste à affecter une plage à une variable variant: Dim vArr comme variante vArr = Range ("B4: z456"). Value2 cela vous donnera une variante contenant un 2-d array Vous pouvez manipuler la matrice et la renvoyer vers Excel Range ("B4: z456") = vArr De même, lorsque des cellules formatées formatent une plage de cellules (probablement en utilisant une copie/pâte spéciale d'une feuille modèle) plutôt qu'une seule cellule. etc. etc. –

0

Il semble que le code VBA (ou le code VB qui écrit sur les feuilles) le fasse ligne par ligne, cela peut prendre du temps et est de mauvaise conception. Ecrire à Excel comme une variante en une seule fois. Formatez la feuille après l'importation des données. Merci Ross