为什么未使用'in'参数修饰符实现Span <t>扩展方法?

时间:2019-01-31 16:53:12

标签: c# .net .net-core

随着C#7.2的发布,出现了in parameter modifierSpan<T> struct。现在,跨域已经泛滥了.NET Core周围的所有API。还发布了.NET标准API(System.Memory),该API支持使用Span<T>ReadOnlySpan<T>等。

System.Memory API的一部分是这些切片类型as seen here的扩展方法。

问题是,为什么不使用in参数修饰符来实现这些扩展方法?由于Span<T>ReadOnlySpan<T>ref readonly struct类型,因此这些方法似乎会导致运行时为传递到这些方法的跨度创建防御性副本。我知道此副本相对便宜,但似乎可以看到很小的性能提升。

这些扩展方法的某些.NET Core实现是located here

为澄清起见,我期望这样的方法签名:

public static int IndexOf<T>(this in System.Span<T> span, T value) where T : System.IEquatable<T>
public static System.ReadOnlySpan<char> Trim(this in System.ReadOnlySpan<char> span)
public static bool IsWhiteSpace(this in System.ReadOnlySpan<char> span)

1 个答案:

答案 0 :(得分:4)

因为in既有优点也有缺点;大多数优点都与结构副本性能有关,并且避免了不必要的大型结构副本(特别强调“大型”),但是Span<T> 并不是大型结构,实际上我见过的所有在in上使用Span<T>的测试要么降低了的性能,或者(较不常见)对性能没有影响-因此即使在最佳情况下(不会降低性能),也没有理由添加它。