How much do CAST statements affect performance?

Question

I have an 800+ line SELECT that I am tuning before using it as the source in an SSIS package. I have reduced the original time it took from around 19 minutes down to just under 2 minutes and now I'm running out of ideas.
My last gain was a 30 second reduction by removing all UDF calls.
There are a large number of CAST statements as my source data needs to be converted for the target table (such as casting decimal as money, varchar as nvarchar, etc.).
Is this likely to have any significant impact on the performance of my statement or not enough to bother about? Maybe using the SSIS convert option would be more efficient?
In some places I have CAST(0 as money). Would it be quicker to define a variable as money with value zero and assign that?
Nick Ryan SQL Server Developer OnePath (NZ) Ltd

Answer 1

There are a large number of CAST statements as my source data needs to be converted for the target table (such as casting decimal as money, varchar as nvarchar, etc.).
Is this likely to have any significant impact on the performance of my statement or not enough to bother about? Maybe using the SSIS convert option would be more efficient?
In some places I have CAST(0 as money). Would it be quicker to define a variable as money with value zero and assign that?
Nick Ryan SQL Server Developer OnePath (NZ) Ltd
As a general rule, doing CASTs or CONVERTs on items in your SELECT clause cost almost nothing.  (Note that CASTs or CONVERTs in WHERE or ON clauses can be very expensive since they will keep SQL Server from making effective use of indexes). 
The reason is it's not expensive in the SELECT clause that most SQL commands take almost all their time doing disk I/O.  But doing the CASTs in a SELECT clause is almost entirely CPU.  And since the CPU is so much faster than the I/O system, the
CASTs don't add much if any time since the CASTs on one group of rows can be done while the I/O system is retrieving the next group of rows and the CPU will finish before the I/O system and then just be sitting there waiting.  As always, there are exceptions
and your mileage may vary.  For example, you might have a server that is already CPU bound for other reasons.
As a test, I ran the following code against a Numbers table that I have that has a bigint column and contains 1,048,575 rows with the numbers from 1 to 1,048,575.
Declare @StartTime datetime2;
Declare @EndTime datetime2;
DBCC FreeProcCache
DBCC DropCleanBuffers
set @StartTime = GETDATE()
select sum(Number) From dbo.Numbers
set @EndTime = GETDATE()
select DateDiff(ms, @StartTime, @EndTime) As 'No Convert'
DBCC FreeProcCache
DBCC DropCleanBuffers
set @StartTime = GETDATE()
select sum(len(Cast(Number As nvarchar(20)))) From dbo.Numbers
set @EndTime = GETDATE()
select DateDiff(ms, @StartTime, @EndTime) As 'With Convert'
As you can see, in one case, I just summed the numbers, in the second, I converted the number, found the length and summed the lengths.  I ran it several times, sometimes the first one was faster, sometimes the second.  They were always within
less than 0.1 seconds of each other.  So the extra function calls on 1,000,000 rows essentially cost nothing.
And I definitely would not worry about CAST(0 AS money).  SQL is smart enough to figure out that that is just a money constant.  So it will just create a constant value of 0 of type money and use that.  It will not do that cast for every row.
Tom