Excel 2k7 wel snel op i7 M620, niet op i7 870

[ChrisM]

Een interessante uitdaging:

We hebben hier een zeer uitgebreid Excel model draaien, waarbij op basis van een groot aantal zeer uitgebreide Excel sheets en allerlei VBA macro's en zelfgeschreven functies (veel copy-paste functies), een rekenmodel wordt gedraaid in Excel 2003. Dit doorrekenen doet, op een oudere PC, ongeveer 5 uur.

Nu is de situatie zo, dat we nieuwe computers aan willen schaffen en over willen stappen op Excel 2007. Hiervoor hebben we een nieuwe ontwikkel PC (zie hieronder voor specs 1) aangeschaft met, naar mijn inziens, zeer goede specs. Het hele model doorrekenen op basis van Excel 2003 gaat hiermee ook een stuk sneller dan voorheen: van 5 uur gaan we nu naar 2.5 uur. Het lijkt dus beter!

Maar dan gaan we overstappen op Excel 2007. Ik heb alle macro's, namen, bestanden, etc. aangepast, zodat het werkt in Excel 2007. Maar de snelheid is helemaal weg: het doorrekenen duurt nu langer dan 15 uur! Dit leek gek, dus we hebben het ook op een andere, moderne PC (zie hieronder voor specs 2) geprobeerd, met Excel 2007, en daar bleek het wel snel te zijn! Er moet dus iets mis zijn met de instellingen van PC 1, maar wat...

Ik heb alles geprobeerd:
Excel 2007 opnieuw installeren, hyperthreading aan, uit, Excel met meer of minder threads laten rekenen, maar 1 processor gebruikt (via BIOS), op een andere harde schijf, automatisch doorrekenen aan en uit... van alles! Maar hij wordt niet sneller... dit terwijl hij op andere PC's dus wel snel rekent, zonder speciale instellingen te doen. Ik heb alle Excel instellingen overgenomen van de andere PCs... maar dat lijkt het niet te zijn.

Mijn vraag is nu: weten jullie nog iets waar ik naar kan kijken, waardoor de performance van Excel 2007 zo belabberd is op de snellere, betere PC?

De specs:
1: De nieuwe PC
Processor: i7 870
Primaire HD: moderne SSD (Intel SSDSA2M080G2HP), hierop staat Windows 7 en Office
Secondaire HD: 7200rpm SATA schrijf (Hitache HDS721010CLA332), voor eventueel extra opslag
Geheugen: 8 GB
Besturingssysteem: Windows 7 Pro 64-bit
Excel: Excel 2007 SP2 32-bit
Grafische kaart: nVidia Geforce 310
Windows Prestatie Index: 4,2 (Processor: 7,5, Geheugen: 7,5, Grafisch: 4,2, Grafisch spellen: 5,9, Primaire HD: 7,6)

2: Andere PC waar het wel snel draait:
Processor: i7 M620
HD: Seagate Momentus 7200.4 ST9500420AS
Geheugen: 8 GB
Besturingssysteem: Windows 7 Pro 64-bit
Excel: Excel 2007 SP2 32-bit
Grafische kaart: nVidia Quadro FX 880M
Windows Prestatie Index: 5,9 (Processor: 6,8, Geheugen: 6,8, Grafisch: 6,5, Grafisch spellen: 6,5, Primaire HD: 5,9)

PC 1 heeft een lagere index, maar dat komt door de grafische kaart. Verder is alles (stukken) beter en sneller... en Excel 2007 gebruikt de grafische kaart toch niet??? Dus dat zou het toch niet kunnen zijn?

Trouwens: ik heb ook nog Excel 2010 geprobeerd op de nieuwe PC. Deze geeft hetzelfde performance probleem...

[ Voor 2% gewijzigd door ChrisM op 10-01-2011 11:37 . Reden: Extra HD toegevoegd aan PC1 ]

[ChrisM]

Iemand nog een idee?

[Maks]

Wat voor SSD zit er in de eerste pc? Was het niet zo dat de wat oudere SSD's slecht waren in sequentieel schrijven?

[ChrisM]

Volgens Apparaatbeheer: Intel SSDSA2M080G2HP

Maar... in PC 1 zitten twee harde schijven: de SSD, maar ook een gewone 7200rpm harde schijf... en het performance probleem is op beide schijven aanwezig.

[FireDrunk]

Kun je niet van beide systemen een complete perfmon draaien op Disk/CPU/MEM/Netwerk?
Dan kan je ze beter vergelijken.

[F_J_K]

ChrisM schreef op maandag 10 januari 2011 @ 11:33:
Maar... in PC 1 zitten twee harde schijven: de SSD, maar ook een gewone 7200rpm harde schijf... en het performance probleem is op beide schijven aanwezig.

Maar een van de twee zal in alle gevallen gebruikt worden voor %tmp%, de pagefile, etc. Je zou die dus als test ook om moeten zetten.
Die SSDSA2M080G2HP is geloof ik behoorlijk snel, maar ik ken er geen schrijf-specs van. Vraag is of er veel naar de HDD wordt geschreven, daarvoor moet je inderdaad 'even' een rapportage met die kentallen maken. Ik kan me best voorstellen dat bijv. de pagefile veel wordt beschreven.

offtopic:
Ik ken natuurlijk de code niet, maar met dit soort tijden is er misschien wat optimalisatie mogelijk - en misschien kan je ook beter geen Excel gebruiken maar een 'echte' applicatie maken of afhankelijk van het soort probleem andere apps gebruiken (Matlab, Mathematica, SPSS, whatever).

[Verwijderd]

je spreekt van copy-paste functies, dus lijkt het erop dat je binnen excel zelf geen performanceoptimalisatie toegepast hebt op de code, zoals bv. het zo weinog mogelijk werken met selecties en verplaatsen van data.
statements zoals application.screenupdating=false/true kunnen de initiële hypothese van impact van de grafische kaart bevestigen.

Excel met meer of minder threads laten rekenen

dat kan vziw enkel door manueel verschillende instanties op te starten en eventueel aan verschillende processors toe te wijzen.

[pedorus]

Verwijderd schreef op maandag 10 januari 2011 @ 13:39:
dat kan vziw enkel door manueel verschillende instanties op te starten en eventueel aan verschillende processors toe te wijzen.

Sinds 2007 is er een optie onder geavanceerd, waar je in kan stellen hoeveel processors je wil gebruiken.

Dit klinkt eigenlijk een beetje alsof je met slecht-geoptimaliseerde macro's werkt, en dan naar de verkeerde oorzaken gaat zoeken om het probleem te verhelpen. Het zou het beste zijn om eens goed naar de performance van de macro's te kijken (zoals ook hierboven staat). Wat bijvoorbeeld zou kunnen, is dat je op pc 1 de VBA-editor nog open had staan en op pc 2 niet.

En als het een erg zwaar model is, is misschien Excel eigenlijk niet de juiste keuze

[ChrisM]

FireDrunk schreef op maandag 10 januari 2011 @ 11:36:
Kun je niet van beide systemen een complete perfmon draaien op Disk/CPU/MEM/Netwerk?
Dan kan je ze beter vergelijken.

Ik heb wat zitten Googlen en (Windows 7) perfmon gestart, maar... hoe doe ik een complete perfmon?

Voor wat betreft de opmerkingen over slecht geoptimaliseerde macro's of andere software: ja... hier hebben we ook aan gedacht. Maar de software is echt zeer specifieke kostprijsmodelleringssoftware. In het verleden hebben hier 3 of 4 jaar lang software ontwikkelaars rondgelopen om voor onze specifieke bedrijfstak deze software te ontwikkelen. Wij wilden dit graag in Excel hebben, omdat we zo volledige vrijheid hebben om alle parameters aan te passen en precies te volgen wat waar te gebeuren. Ook is het uit Excel gemakkelijker te exporteren en te analyseren.

Maar goed, dat ze slecht-geoptimaliseerd zijn... dat kan het probleem eigenlijk niet zijn: waarom zijn ze dan op de ene moderne PC wel snel en op de een andere niet? Het lijkt me echt iets specifieks te zijn aan die ene PC... maar, bijv. grafische kaart... in Excel? Serieus??? Kan dat? Ik kan het gaan proberen......

pedorus schreef op maandag 10 januari 2011 @ 14:30:
Wat bijvoorbeeld zou kunnen, is dat je op pc 1 de VBA-editor nog open had staan en op pc 2 niet.

Heb ik geprobeerd: alles staat hetzelfde, beiden hebben de VBA-editor gesloten.

[F_J_K]

Perfmon: start het op, voeg met + relevante kentallen toe, start Excel en doe een run. Kijk vervolgens na een tijdje wat de verschillende getallen doen. Blijft de CPU laag? Dan is die geen bottleneck, is er veel datatransfer? Dan dat wel. Etc. Er zijn ook tools die de data kunnen helpen analyseren. Afhankelijk van je OS kan dan misschien iets als http://pal.codeplex.com/releases/view/21261 helpen.

application.screenupdating=false is een must-have als er veel aanpasingen zijn in Excel + VBA, ik mag hopen dat dat al gebruikt was. Anders wil je geld terugvragen van de devvers

offtopic:
Parametriseerbaar zijn en import/export-mogelijkheden zijn geen van beide redenen om iets in Excel te doen. Zonder te weten hoe rekenintensief het is (en in hoeverre het uitmaakt dat het 5, 10 of 15 uur duurt) kunnen we natuurlijk niet zeggen of er veel optimalisatie binnen Excel nodig is - maar als ik zou mogen gokken dan zou ik zeggen dat (met alle kennis van de huidige code in het achterhoofd) een migratie sneller, goedkoper en toekomstvaster is dan een optimalisatieslag (en dan een paar jaar later opnieuw, als er iets niet backwards compatible blijkt in Office 20xx).

Maar goed, dat is nu niet direct relevant. Kijk dus wat er met HDD, geheugen, CPU, etc gebeurt om te zien wat de bottleneck is.

[pedorus]

ChrisM schreef op maandag 10 januari 2011 @ 19:16:
Maar goed, dat ze slecht-geoptimaliseerd zijn... dat kan het probleem eigenlijk niet zijn: waarom zijn ze dan op de ene moderne PC wel snel en op de een andere niet? Het lijkt me echt iets specifieks te zijn aan die ene PC... maar, bijv. grafische kaart... in Excel? Serieus??? Kan dat? Ik kan het gaan proberen......

Het grafische kaart verhaal lijkt me ook wat onwaarschijnlijk. Maar eigenlijk vraag je waarom een willekeurig stuk software veel langzamer draait op pc1 dan op pc2. Zonder dat we in de black-box van vba-code en formules kunnen kijken is dat knap lastig te beantwoorden...

Wat ik wel in zijn algemeenheid kan zeggen is dat trage methodes in Excel zomaar factoren duizend trager kunnen zijn. Het stukje "veel copy-paste functies" voorspelt niet veel goeds.