Bei großen Datenbanken bedeutet das die Weitergabe von Hunderten von Tabellen, inklusive deren Feldstrukturen und Sortierungen. Wenn Relationen verwendet werden, könnten Tabellen in der Struktur sogar mehrfach auftauchen, als Basistabellen und als 1:1-verknüpfte Tabellen. Da hat man dann schnell buchstäblich Millionen von API-Aufrufen und Tausende von Datenbankabfragen. Wir haben uns zuvor um die Performance der Tree View gekümmert, haben damit aber nur die Symptome bekämpft. Die Startgeschwindigkeit des Designers war immer noch viel langsamer als gewünscht.
Mit LL23 können wir nun endlich ein Feature einsetzen, das wir schon seit langem im Sinn hatten: verzögert geladene Daten im Designer. Dieses Feature funktioniert für alle Anwendungen, die einen Datenprovider einsetzen, d. h. für .NET und C++ Anwendungen. Um Ihnen Zahlen zum Vergleich liefern zu können, habe ich die AdventureWorks SQL Server Demodatenbank als Referenz benutzt. Folgendes kam auf meinem Rechner dabei heraus:
|
Messwert |
LL22 |
LL23 |
|
Arbeitsspeicher |
67,5 MB |
41,8 MB |
|
Anzahl Datenbankabfragen |
630 |
2 |
|
Zeit, bis Designer öffnet |
5,7 s |
0,9 s |
Die verbleibenden beiden Abfragen sind nötig, um Informationen über Schlüsselfelder und Relationen zu erhalten.
Dank dieser enormen Performancesteigerung beim Start kann man jetzt ganze Datenbanken weitergeben, wo bisher eine Auswahl getroffen werden musste. Das erspart Ihnen Ihre eigenen Vorauswahldialoge oder das Rekompilieren Ihrer Anwendung mit „noch einer Tabelle mehr“. Der psychologische Effekt auf Ihre Anwender ist groß – eine Verkürzung der Startverzögerung um mehr als 80 % wie in meinem Testfall wird deutlich spürbar sein. Und Ihr Datenbank-Administrator wird dieses Update ebenfalls schätzen.
Um einen Eindruck der Auswirkungen dieser Änderungen zu bekommen, schauen Sie sich diese beiden Videos an, je eines zu LL22 und LL23. Sie zeigen den Start des Designers bei einem Kollegen mit der Adventure Works Datenbank, dieses Mal allerdings ohne lokalen Server (wie bei meinen Daten), sondern mit einem SQL Server in unserem Intranet. Im Diagnostic Tool Fenster rechts sehen Sie die Speichernutzung inklusive CLR Heaps, daher ist diese auch höher als in der Tabelle oben, sowie die Abfragen, die auf die Datenbank gefeuert wurden und die CPU Last. Der Designer startet nach 13,8 Sekunden bei LL22. Schauen Sie sich die Zeit bei LL23 selbst an:
Designer Start mit List & Label 22:
Designer Start mit List & Label 23:
Der Web Designer wird von diesem Feature sogar noch mehr profitieren. Bisher mussten wir die gesamten Feldinformationen vom Server zum Client übertragen, was extreme Spitzenbelastungen sowohl bei der Server CPU als auch bei der Netzwerkbandbreite zur Folge hatte. Jetzt müssen wir einfach nur einige grundlegende Informationen über die Tabellen und Relationen weiterleiten und können die aufwändigen Abfragen so lange aufschieben, bis sie wirklich gebraucht werden. In einigen Wochen werde ich mehr über die Merkmale des neuen Web Designers zu einem entsprechenden Thema bloggen. Bleiben Sie dran
Jochen Bartlau leitet als Geschäftsführer die Softwareentwicklung bei combit. Microsoft .NET und Agiles Projektmanagement sind zwei seiner Steckenpferde. Der technikbegeisterte Physiker und Vanlife-Enthusiast verbringt seine Freizeit am liebsten beim Wandern.
