FileStream.ReadByte - 效率低下 - 这是什么意思？

Stream上的默认实现会创建一个新的单字节数组，然后调用Read。虽然这是正确的，但效率不高。任何带有内部缓冲区的流都应该重写此方法，并提供更高效的版本，以便直接读取缓冲区，从而避免每次调用都分配额外的数组。FileStream.ReadByte - 效率低下 - 这是什么意思？

从FileStream.ReadByte资料为准：

http://msdn.microsoft.com/en-us/library/system.io.filestream.readbyte.aspx

什么是这个meaing，如何克服这种低效率？

来源

2010-10-22 MC Hammer

你想做什么？ – SLaks 2010-10-22 14:57:01

确定上述引用的含义，以便我可以根据上述含义做出合理的决定。 – 2010-10-22 15:00:55

这是您从Stream继承的唯一问题。这样做时，您必须提供至少一个Read方法，ReadByte在其基类中实现。这很好，但是当你的数据流能够直接获取单个字节时效率低下 - 默认实现会首先在内部创建一个单字节缓冲区，将它传递到ReadByte来填充它，然后返回单个字节。如果你可以实现你的缓冲区，这样单个字节可以直接返回，而不需要分配一个临时缓冲区，你应该这样做。

对于调用代码，唯一的考虑是，当您需要读取字节以将它们存储在缓冲区中时，即使只读取单个字节，Read通常也会比ReadByte效率更高 - 但如果您真的只需要一个字节，并且您使用的流实现提供了一个优化版本，ReadByte实际上可能会更快。如果您读取单个字节进行即时处理，ReadByte应该不会成为问题 - 毕竟，大多数标准流类已经被缓冲了，应该提供经过优化的ReadByte。如果有疑问，简介。

来源

2010-10-22 15:09:33 tdammers

您需要使用Read方法读取到缓冲区。读单字节效率不高。使用缓冲：

byte[] buffer = new byte[4096]; // 4K 
    int bytesRead =0; 
    while((bytesRead = stream.Read(buffer, 0, buffer.Length))>0) 
    { 
    // Do whatever with buffer 
    }

来源

2010-10-22 15:00:13 Aliostad

我会读，作为一个非常写得不好的方式说“不使用ReadByte（），并使用Read()代替”。特别是由于Read（）的文档说

此方法覆盖Read。

在备注部分。

来源

2010-10-22 15:00:30 David

那么，意义似乎相当明确 - 解决方法是根本不要致电ReadByte。

不要一次读取一个字节 - 使用Read(byte[], int, int)方法读入适当大小的缓冲区（通常约8K，但大约几个数量级的任何应该都可以）。如果您之后需要逐个读取字节，请从缓冲区逐个读取一个字节。

如果你需要确保自己的读数不超过你的意思，那么这就成了一个问题，如果你明白我的意思 - 例如你不打算读取第一个0字节，例如，因为这意味着它是下一个“消息”的开始，你希望能够在以后再读。理想情况下，避免将自己设计成这种情况。

结束语在这种情况下，一个BufferedStream可能帮助下FileStream，但我会仔细衡量性能，如果是重要的......并且还是尽量避免需要一次读取一个字节的设计，如果你能帮助它。

来源

2010-10-22 15:00:33

FileStream.ReadByte - 效率低下 - 这是什么意思？

回答

相关问题