SQL Server：为什么CLR函数比CLR存储过程快？

Question

I came across the debate of CLR function may be faster than T-SQL scalar function for some people or the other way round for another group of people.

And I also read about comparing CLR function with CLR stored procedure and I learn that CLR function is faster than CLR stored procedure. Can someone explain to me, in technical, why a CLR function is faster?

I'm new to CLR and currently developing a CLR stored procedure in C# to be used in SQL Server. The CLR execution basically consume 0 seconds even after many tried. I haven't tried implementing into an actual T-SQL stored procedure yet but I need to do that to produce the expected result. So I want to understand the execution part and determine which method to use

Answer 1

I don't think that a SQLCLR Scalar User-Defined Function (UDF) is necessarily faster than a SQLCLR Stored Procedure. I think it would depend on what the operation is and how it is being used. One advantage that some SQLCLR UDFs have the ability to make use of is, if there is no data access (and sometimes, though not always, if IsDeterministic is set to true ), then they can participate in parallel plans. This is not something that T-SQL UDFs can do. So, for operations that can be done in a UDF (not all can be, some require being done in a Stored Procedure), that do not do any data access, and that are being called repetitively in a single query, this can provide a performance improvement over Stored Procedures, which cannot be called in set-based fashion.

For more information on working with SQLCLR in general, please see the series of articles I am writing on the topic on SQL Server Central: Stairway to SQLCLR

PS If you are going to state that you "came across a debate" and then "read about" some topic, you really should provide the links to those discussions and articles / posts, assuming that they are not in private forums or on a corporate intranet. It really helps to have the context of what is being said, especially to help ensure that you weren't simply misreading / misunderstanding what you have found (and yes, that has happened).