title: Performance value of COMB guids
body: <p>Jimmy Nilsson discusses his COMB guid concept <a href="http://www.informit.com/articles/article.aspx?p=25862&amp;seqNum=7" rel="nofollow noreferrer">here</a>. This concept is popular in NHibernate, among other circles, for its supposed performance value over standard GUIDs which are typically far more random.</p>
  
  <p>However, in testing, this does not appear to be the case. Am I missing something?</p>
  
  <p>Test case:</p>
  
  <p>I have a table called temp (not a temp table, just a table named "temp") with 585,000 rows in it. I have a new table called Codes, and wish to copy all 585,000 code values from the temp table to the codes table. The test SQL I executed was:</p>
  
  <pre><code>set statistics time on;
  
  truncate table codes;
  DBCC DBREINDEX ('codes', '', 90);
  
  insert into codes (codeid, codevalue)
  select newid(), codevalue from temp
  
  truncate table codes;
  DBCC DBREINDEX ('codes', '', 90);
  
  insert into codes (codeid, codevalue)
  select CAST(CAST(NEWID() AS BINARY(10)) + CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER), codevalue from temp
  </code></pre>
  
  <p>Performance with standard GUID values:</p>
  
  <blockquote>
    <p>SQL Server Execution Times:    CPU
    time = 17250 ms,  elapsed time = 15735
    ms.</p>
    
    <p>(585000 row(s) affected)</p>
  </blockquote>
  
  <p>Performance with COMB GUID values:</p>
  
  <blockquote>
    <p>SQL Server Execution Times:    CPU
    time = 17500 ms,  elapsed time = 16419
    ms.</p>
    
    <p>(585000 row(s) affected)</p>
  </blockquote>
  
  <p>What am I missing? the COMB GUID values resulted in slightly longer times, presumably because of the additional conversions. I thought the point was to reduce the insert time by semi-ordering the GUIDS using the date for the last 6 bytes, but the performance gain appears non-existent.</p>