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 - 效率低下 - 這是什麼意思？

回答

相關問題