Overblog Folge diesem Blog
Edit post Administration Create my blog
Blog von Olaf Helper

Performance Test der CLR User Aggregation FirstString und LastString

14. Juli 2009 , Geschrieben von Olaf Helper Veröffentlicht in #.NET

Die Implementierung einer eigenen CLR Aggregation, wie FirstString / LastString aus meinem Blog, ist sehr einfach umzusetzen. Nun stellt sich mir noch die Frage: Wie performant ist das gegenüber den integrierten Aggregationen wie MIN / MAX?

Also machen wir mal einen Test. Basis soll eine einfache Tabelle mit einem VarChar Feld sein ohne jeden Index; es soll eh über alles aggregiert werden und da wird sowieso ein Full-Table-Scan ausgelöst. Zunächst eben die Tabelle mit 50.000 Einträgen anlegen, auf meinem Notebook dauert das ca.  55 Sekunden.

 -- Performance-Test für CLR Aggregation FIRST / LAST 
 -- gegenüber den integrierten MIN /MAX bei Strings 
 SET STATISTICS TIME OFF; 
 GO 
 CREATE TABLE AggrTest (String varchar(20)); 
 GO 
 SET NOCOUNT ON; 
 DECLARE @loop int; SET @loop = 0; 
 WHILE @loop < 100000 
 BEGIN 
  INSERT INTO AggrTest  
   VALUES (RIGHT(REPLICATE('0', 20) + CONVERT(varchar(20), @loop), 20)); 
  SET @loop = @loop + 1; 
 END -- Dauer ca.  
 GO 

 

Da ich schon ahne, was auftreten wird, habe ich einmal den Sql Server Dienst neu gestartet, damit die damit mein Assembly OlafHelper.SqlServer.Aggregate auch nicht geladen. Ist.

Hier nun das Test-Script, zunächst Min/Max und dann FirstString/LastString. Dazwischen wird der Procedure und Daten-Cache gelöscht.

 -- Cache & Co löschen 
 DBCC FREEPROCCACHE WITH NO_INFOMSGS; 
 DBCC DROPCLEANBUFFERS WITH NO_INFOMSGS; 
 GO 
 PRINT 'Min/Max' 
 SET STATISTICS TIME ON 
 GO 
   
 -- Nun die Zeitmessung 
 SELECT MIN(String), MAX(String) 
 FROM AggrTest 
 GO 
 SET STATISTICS TIME OFF; 
 GO 
 -- Cache & Co löschen 
 DBCC FREEPROCCACHE WITH NO_INFOMSGS; 
 DBCC DROPCLEANBUFFERS WITH NO_INFOMSGS; 
 GO 
 PRINT 'First/LastString' 
 SET STATISTICS TIME ON; 
 GO 
   
 SELECT dbo.FirstString(String), dbo.LastString(String) 
 FROM AggrTest 
 GO 
 SET STATISTICS TIME OFF; 
 -- Aufräumen 
 DROP TABLE AggrTest 

 

Ergebnis der ersten Ausführung:

 

Min/Max

SQL Server-Analyse- und Kompilierzeit: CPU-Zeit = 16 ms, verstrichene Zeit = 16 ms.

SQL Server-Ausführungszeiten:             CPU-Zeit = 218 ms, verstrichene Zeit = 252 ms.

SQL Server-Analyse- und Kompilierzeit: CPU-Zeit = 0 ms, verstrichene Zeit = 0 ms.

 

First/LastString

SQL Server-Analyse- und Kompilierzeit: CPU-Zeit = 578 ms, verstrichene Zeit = 1317 ms.

SQL Server-Ausführungszeiten:             CPU-Zeit = 374 ms, verstrichene Zeit = 449 ms.

SQL Server-Analyse- und Kompilierzeit: CPU-Zeit = 0 ms, verstrichene Zeit = 0 ms.

 

Ergebnis der zweiten Ausführung:

 

Min/Max

SQL Server-Analyse- und Kompilierzeit: CPU-Zeit = 0 ms, verstrichene Zeit = 26 ms.

 SQL Server-Ausführungszeiten:            CPU-Zeit = 188 ms, verstrichene Zeit = 257 ms.

SQL Server-Analyse- und Kompilierzeit: CPU-Zeit = 0 ms, verstrichene Zeit = 0 ms.

 

First/LastString

SQL Server-Analyse- und Kompilierzeit: CPU-Zeit = 0 ms, verstrichene Zeit = 25 ms.

SQL Server-Ausführungszeiten:             CPU-Zeit = 265 ms, verstrichene Zeit = 330 ms.

SQL Server-Analyse- und Kompilierzeit: CPU-Zeit = 0 ms, verstrichene Zeit = 0 ms.

 

Der Grund für die großen Unterschiede zwischen der ersten und zweiten Ausführung ist einfach, denn nach dem Sql Server Dienst-Neustart muss zunächst einmal das CLR Assembly geladen werden. Einmal im Speicher ist die Ausführung gleich schneller und

Diesen Post teilen

Repost 0

Kommentiere diesen Post