É seguro usar Strings em vez de SqlStrings para parâmetros de entrada da função CLR?

Excelente pergunta. Até onde eu sei, nessas condições (ou seja, sem garantias NULLe sem necessidade de funcionalidade extra), não deve haver nenhuma preocupação específica. Esta poderia ser uma situação semelhante a CURSORs onde, se uma regra genérica for necessária, seria: "não use cursores". Mas, a regra atual é: "só use cursores quando/onde apropriado". O problema é educar as pessoas sobre os detalhes técnicos dos cursores para que possam tomar essa decisão, ou seja, aqueles de nós que sabem o suficiente sobre essas coisas ignoram a regra genérica e passam a usá-los adequadamente.

Então, eu aconselho as pessoas a "sempre" usar os Sql*tipos porque isso reduz a confusão e os erros. Mas, isso não quer dizer que usar stringem sua situação não seria melhor. Eu digo vá em frente, e se você tiver algum problema com string, é fácil voltar e mudar para SqlString.

Com relação ao agrupamento e sua declaração de:

Se for importante, estou usando o agrupamento padrão do SQL Server.

Embora geralmente não importe, também não está claro o que você quer dizer aqui, pois não há um agrupamento padrão verdadeiro. É provável que você esteja se referindo ao infeliz agrupamento padrão ao instalar o SQL Server em um sistema operacional com uma configuração de idioma "inglês americano" (ou seja, LCID = 1033), que é SQL_Latin1_General_CP1_CI_AS. Mas ainda há três níveis de agrupamentos que podem ser todos diferentes (Instância/Servidor, Banco de Dados e Coluna), e você pode estar significando apenas um ou até dois desses níveis.

A razão pela qual menciono tudo isso é que há algumas coisas não óbvias acontecendo aqui:

1. até certo ponto, nenhum desses 3 níveis que os agrupamentos afetam é relevante, pois a cultura padrão dos threads SQLCLR é a configuração de idioma no nível do sistema operacional (o LCID do idioma selecionado). Isso afeta as operações usando String.Equalsao usar um dos dois StringComparison.CurrentCulture*valores e as operações usando String.Compareao não especificar uma cultura.

2. até certo ponto, nenhum desses 3 níveis que os agrupamentos afetam é relevante, pois o =operador faz uma comparação ordinal (ou seja, deve ser o mesmo que usar um _BIN2agrupamento). É assim também que String.CompareOrdinalfunciona, assim como String.Equalsquando não passa StringComparison.CurrentCulture*ou StringComparison.InvariantCulture*valores.

3. uma instância em que o agrupamento do SQL Server é importante é ao concatenar um SqlStringparâmetro de entrada com um stringvia +. Nesse caso, o +operador cria um new SqlStringpara conter o valor de stringpara que possa concatenar os dois SqlStrings. O problema é que o novo SqlStringé criado com os threads atuais LCID (que é o LCID do Sistema Operacional), e então o +operador compara os dois SqlStringss antes da concatenação (ou seja, verifica se eles são do "mesmo tipo"). Mas, devido ao SqlStringparâmetro de entrada ter o LCID do banco de dados (não instância ou coluna) e o parâmetro criado implicitamenteSqlStringtendo um LCID do sistema operacional, a operação obtém uma exceção informando que os "agrupamentos" não correspondem. Legal, hein?

   Isso, no entanto, não deve ser um problema, pois ninguém deve usar o SqlStringvalor diretamente ao desejar a string. Em vez disso, todos devem sempre usar a Valuepropriedade para obter a string.

Dito isto, estou curioso para saber qual teste você fez para determinar que stringfoi mais rápido. Testei uma UDF simples que aceita um único NVARCHAR(4000)parâmetro de entrada, concatena uma string curta e depois retorna o novo valor. Uma versão dessa UDF aceita e retorna string, e a outra versão aceita e retorna SqlString. Mais de 1 milhão de iterações, a stringversão foi cerca de 200-300 milissegundos mais rápida do que a SqlStringversão, cerca de 50% do tempo, ao comparar seus tempos mais rápidos (em todas as 1 milhão de iterações, não por cada). Nos outros 50% do tempo, o ganho de desempenho foi de cerca de 100 milissegundos, mas também pode ser nenhum.

Além disso, em relação ao seu código de teste: é s1sempre o parâmetro de entrada direta, seja stringou SqlString? Se sim, você também deve testar a criação de uma string localmente e defini-la s1.Value. Significado:

string s2 = s1.Value; // when s1 is SqlString instead of string

fixed (char* chptr = s2)
{
    char* cp = (char*)current;

    for (int i = 0; i < s2.Length; i++)
    {
        cp[i] = chptr[i];
    }
}

Além disso, algumas outras opções para possivelmente testar:

1. Método SqlString.GetUnicodeBytes (retorna byte[])
2. Propriedade SqlChars.Value (retorna char[])