Ivan Petrov's questions

Neste vídeo recente de Nick Chapsas, no final ele comentou que o Findmétodo on List<T>era "não otimizado" porque o código não itera no Span do array, mas no próprio array:

public T? Find(Predicate<T> match) {
    if (match == null) {
        ThrowHelper.ThrowArgumentNullException(ExceptionArgument.match);
    }

    for (int i = 0; i < _size; i++) {
        if (match(_items[i])) {
            return _items[i];
        }
    }
    return default;
}

Achei que a iteração em spans poderia ser feita tão rápido quanto em arrays (mas não mais rápido) a partir deste parágrafo da postagem do blog (atualizada?) de Stephen Toub sobre Spans:

O código assembly é tão similar em parte por causa da eliminação de verificações de limites. Mas também é relevante o reconhecimento do JIT do indexador span como um intrínseco, o que significa que o JIT gera código especial para o indexador, em vez de traduzir seu código IL real para assembly.

Tudo isso serve para ilustrar que o tempo de execução pode aplicar aos spans os mesmos tipos de otimizações que aplica aos arrays , tornando os spans um mecanismo eficiente para acessar dados.

Quando se tornou evidente que iterar no Span de um array seria tão rápido e talvez mais rápido do que apenas iterar no próprio array? Qual versão do .NET introduziu essas otimizações de JIT Span que não podiam ser usadas para arrays?

Para o estático, DispatchProxy.Create<T,TProxy>()a documentação nos diz que:

Cria uma instância de objeto que deriva da classe TProxye implementa a interface T.

Ter o seguinte código de teste confirma que:

interface I{
    void Foo();
}

class D : DispatchProxy {
    protected override object Invoke(MethodInfo targetMethod, object[] args) {
        Console.WriteLine("In Invoke");
        return null;
    }
    public virtual void DMethod(){
    }
}

var proxy = DispatchProxy.Create<I,D>();
Console.WriteLine(proxy.GetType().BaseType); // typeof(D)
Console.WriteLine(proxy is I); // true

Então a parte interessante sobre o Invokemétodo de acordo com os documentos :

Sempre que qualquer método no tipo de proxy gerado é chamado, esse método é invocado para despachar o controle.

Isso pode significar

proxy
.GetType()
.GetMethods(BindingFlags.NonPublic|BindingFlags.Public|BindingFlags.Instance|BindingFlags.Static)
.Select(x => x.Name)

o que nos dá

Foo Invoke DMethod GetType MemberwiseClone Finalize ToString É igual a GetHashCode

mas se testarmos se chamamos Invoketanto o método de interface quanto o método de classe de despacho:

proxy.Foo(); // In Invoke
((D)proxy).DMethod(); // nothing

Observando como DispatchProxyo tipo de proxy gerado é implementado com um campo privado com uma matriz de MethodInfos que são usados ​​nos métodos stub com chamadas para Invokeele, fará sentido que só possamos ter esse comportamento com métodos que podemos substituir.

É por isso que defini o DMethod como virtual, mas aparentemente nenhum stub foi criado.

Isso significa que os documentos devem declarar:

Sempre que qualquer método de interface >>> no tipo de proxy gerado é chamado, este método é invocado para despachar o controle.