C# 是否需要缓冲文本阅读器？

缓冲

文本阅读器有什么意义吗

TextReader
有自己的内部缓冲区，我可以在创建时设置大小，那么我是否有理由想使用自己的缓冲区并调用
Read（缓冲区、索引、计数）
而不是使用
Read（）
？谁知道Read（）方法的内部有多复杂？希望它们被优化为尽可能快和高效。但是很可能调用单个Read（…）方法，然后在字符数组上迭代会更快。但另一个重要的问题是：在您的情况下，性能差异是什么重要吗？如果你只是一分钟读一到两次100个字符，那么性能可能并不重要。如果要按顺序处理多兆字节的文件，则可能需要最佳性能。如果是后者，那么同样的答案总是适用的：测量，不要猜测。
这取决于你在做什么。如果您从流中读取的固定长度记录不是由CR+LF对分隔的，那么您需要按照

public static void Process()
{
  using ( Stream s = OpenCommunicationsStream() )
  using ( TextReader tr = new StreamReader(s)   )
  {
    char[] record = char[80] ;
    int chars_read ;

    while ( (chars_read=tr.Read(record,0,record.Length)) == record.Length )
    {
      DoSomethingWithRecord( record ) ;
    }
    if ( chars_read > 0 ) throw new InvalidDataException("wrong length record") ;
  }
  return ;
}

使用
Read/0
而不是
Read/3
或
ReadBlock/3
的原因完全取决于您的需要和上下文。例如，如果您正在编写解析器，您可能希望逐个字符地处理入站文本流，特别是因为
TextReader
通过其
Peek（）
方法免费为您提供一个前瞻字符。
多字节字符现在非常流行，如果您真的在阅读字符，那么在数组上迭代可能会更快。需要更快吗？在性能出现问题之前，“更可读”可能更可取？我需要读取和处理流中的每个字符。使用缓冲读取似乎是更快的方法。即使在读取后迭代缓冲区中的所有字符，速度仍然更快。这是许多开发人员从未得到的一个重要教训：解决方案中的代码越多并不意味着速度就越慢。许多开发人员认为，如果他们编写的代码更少，这就意味着解决方案会更快。没有免费的午餐。您必须考虑调用的方法中包含了多少代码。这些方法可以让开发者的生活更轻松。但这通常意味着这些方法的设计要比开发人员所做的更多。结果是：如果开发人员专门为解决方案编写代码，速度会快很多倍。