First and definitely not least – die Performance des Visual Basic 2008-Compilers
Es gibt eine ganze Reihe an Kleinigkeiten, die das Visual Basic 2008-Team in das neue Visual Basic 2008 integriert hat. Es gibt auch Dinge, die man nicht sieht, die aber dennoch von Wichtigkeit sind – und das ist die Performance des Compilers, mal ganz davon zu schweigen, dass er reibungslos funktionieren und nicht hier und da »mal« abstürzen sollte.
Letzteres war nämlich vor dem Service Pack 1 beim Visual Basic 2005-Compiler gerade auf Mehrprozessor- oder Multi-Core-Prozessor-Systemen bei größeren Projekten sehr häufig der Fall. Mitunter mussten Projekte sogar liegen bleiben, bis die ersten Patches für diese »Race-Condition«, die sich zwischen Editor und Background-Compiler wohl entwickelte, vom Visual Basic-Team »geklärt« war.
Doch das ist glücklicherweise Schnee von gestern. Heute geht es nicht darum, dass der Compiler richtig funktioniert (denn das tut er!), sondern wie schnell. Hier ist in Sachen Produktivität einiges an Steigerungspotential herauszuholen, und die Jungs und Mädels aus Redmond haben sich das richtig zu Herzen genommen; im Falle von Visual Basic 2008 übrigens eher sogar die Mädels.
Im Folgenden finden Sie eine Tabelle , die die Performance-Unterschiede zum Visual Basic 2005-Compiler dokumentiert – diese Tabelle stammt übrigens ursprünglich aus einem Blog von Lisa Feigenbaum, einer der Entwicklerinnen im Visual Basic 2008-Team.
Verstehen Sie die Tabelle bitte nicht falsch: Es geht dabei nicht um die Geschwindigkeit, mit der die späteren Programme laufen, sondern wie schnell Background-Compiler und Main-Compiler arbeiten und damit wie groß (oder: klein) die Turn-Around-Zeiten beim Kompilierungsprozess sind.
| Szenario |
VB2005 (ms) |
VB2008 (ms) |
VB2008 ist x-mal schneller als VB2005 |
VB2008 braucht x% der Zeit von VB2005 |
Build eines umfangreichen Projektes (bei Verwendung von Hintergrund-Kompilierung mit dem Background-Compiler). |
222206.25 |
1352.88 |
164.25 |
0.61% |
Build einer großen Projektmappe mit mehreren Projekten (explizite Build-Erstellung). |
1618604.75 |
57542.75 |
28.13 |
3.56% |
Build einer großen Projektmappe mit mehreren Projekten (bei Verwendung von Hintergrund-Kompilierung mit dem Background-Compiler). |
222925.50 |
19861.88 |
11.22 |
8.91% |
Reaktionszeit nach dem Hinzufügen eines Members zu einer Klasse. |
327.00 |
36.50 |
8.96 |
11.16% |
Reaktionszeit nach dem Öffnen eines Projekts. |
255551.25 |
38769.38 |
6.59 |
15.17% |
IntelliSense aufrufen, um die Typenliste anzeigen zu lassen (erster Aufruf). |
1192.50 |
530.5 |
2.25 |
44.49% |
Edit-and-Continue in einer Projektmappe, die XML-Kommentare enthält (erstes Mal). |
441.25 |
210.5 |
2.10 |
47.71% |
Reaktionszeit nach dem Ändern eines Methoden-Statements. |
390.25 |
236.38 |
1.65 |
60.57% |
10 Schritte im Debugger (kummulierte Zeiten). |
1850.75 |
1167.13 |
1.59 |
63.06% |
IntelliSense aufrufen, um eine Typenliste zu bearbeiten (Folgezeiten). |
79.25 |
51.5 |
1.54 |
64.98% |
Ausführen nach F5 wenn die Projektmappe bereits vollständig erstellt wurde. |
385.20 |
278.7 |
1.38 |
72.35% |
Zeit, nachdem ein Fehler der Fehlerliste hinzugefügt wird. |
531.25 |
394.5 |
1.35 |
74.26% |
10 Schritte im Debugger (zum ersten Mal). |
1336.50 |
1150 |
1.16 |
86.05% |
Reaktionsverhalten, während der Hintergrundcompiler eine offene Projektmappe verarbeitet. |
4803.00 |
4284.75 |
1.12 |
89.21% |
Laden einer umfangreichen Projektmappe. |
13667.5 |
12407.25 |
1.10 |
90.78% |
Laden einer umfangreichen Projektmappe (erstmalig).
Hinweis: Entspricht der Verbesserung auf Windows XP. Unter Vista ist der Geschwindigkeitsvorteil noch mal doppelt so schnell. |
19946.25 |
18222 |
1.09 |
91.36%
|
Quelle Lisa Feigenbaum, Stand 18.1.2008.
|