Do CLR DLLs use more memory / slow SQL server?

We has some response issue with minor schema changes.
Except we're using some C# DLLs now.
Kyle JedrusiakBasically, it is not how you do it, it is what you that counts. If you write procedural code instead
of set-based code, it will in vast majority of cases be much slower. CLR has some overhead, so for
cases where you can do the same with TSQL (set based queries etc), CLR will perform worse. But not
as much as you would think (if you know the architecture behind the CLR integration). My guess is
either change of query plans or procedural logic.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Kyle Jedrusiak" <kjedrusiak@.princetoninformation.com> wrote in message
news:%23tHqUaLvGHA.4460@.TK2MSFTNGP05.phx.gbl...
> We has some response issue with minor schema changes.
> Except we're using some C# DLLs now.
> Kyle Jedrusiak
>|||We basically replaced a lot of string manipulation stuff with c# code.
Not doing any record manipulation.
Kyle!
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:OTByEiLvGHA.1956@.TK2MSFTNGP02.phx.gbl...
> Basically, it is not how you do it, it is what you that counts. If you
> write procedural code instead of set-based code, it will in vast majority
> of cases be much slower. CLR has some overhead, so for cases where you can
> do the same with TSQL (set based queries etc), CLR will perform worse. But
> not as much as you would think (if you know the architecture behind the
> CLR integration). My guess is either change of query plans or procedural
> logic.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Kyle Jedrusiak" <kjedrusiak@.princetoninformation.com> wrote in message
> news:%23tHqUaLvGHA.4460@.TK2MSFTNGP05.phx.gbl...
>> We has some response issue with minor schema changes.
>> Except we're using some C# DLLs now.
>> Kyle Jedrusiak
>|||String manipulation can be a good candidate for SQLCLR, but we can't say without any knowledge of
what you do and how you do it. Again, if you degraded set based code to procedural code, you will
most probably see worse performance. If you used CLR for the right reasons, the problem is
elsewhere, like SQL Server selecting different execution plans.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Kyle Jedrusiak" <kjedrusiak@.princetoninformation.com> wrote in message
news:uXbLckLvGHA.5056@.TK2MSFTNGP06.phx.gbl...
> We basically replaced a lot of string manipulation stuff with c# code.
> Not doing any record manipulation.
> Kyle!
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in message
> news:OTByEiLvGHA.1956@.TK2MSFTNGP02.phx.gbl...
>> Basically, it is not how you do it, it is what you that counts. If you write procedural code
>> instead of set-based code, it will in vast majority of cases be much slower. CLR has some
>> overhead, so for cases where you can do the same with TSQL (set based queries etc), CLR will
>> perform worse. But not as much as you would think (if you know the architecture behind the CLR
>> integration). My guess is either change of query plans or procedural logic.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "Kyle Jedrusiak" <kjedrusiak@.princetoninformation.com> wrote in message
>> news:%23tHqUaLvGHA.4460@.TK2MSFTNGP05.phx.gbl...
>> We has some response issue with minor schema changes.
>> Except we're using some C# DLLs now.
>> Kyle Jedrusiak
>>
>