Я бы так не поступил, как у вас здесь.
Учтите, что вам необходимо предоставить свойство типа Stream
(что такое BinaryReader.BaseStream
). Поэтому вам нужно создать свой собственный класс, основанный на Stream
. Этот класс должен:
- взять ссылку на
FastBinaryReader
, чтобы он мог переопределить Stream.Length
и Stream.Offset
, делегировав FastBinaryReader
элемент
- взять ссылку на
Stream
(ту же, что передана в конструкторе FastBinaryReader
), чтобы делегировать все другие операции этому потоку (вместо этого вы могли бы иметь эти throw new NotImplementedException()
, но вы никогда не знаете, какой метод библиотеки позвонит им!)
Вы можете представить, как это будет выглядеть:
private class StreamWrapper : Stream
{
private readonly FastBinaryReader reader;
private readonly Stream baseStream;
public StreamWrapper(FastBinaryReader reader, Stream baseStream)
{
this.reader = reader;
this.baseStream = baseStream;
}
public override long Length
{
get { return reader.Length; }
}
public override long Position
{
get { return reader.Position; }
set { reader.Position = value; }
}
// Override all other Stream virtuals as well
}
Это бы сработало, но мне кажется немного неуклюжим. Логическим продолжением было бы поместить кэширование в StreamWrapper
вместо внутри FastBinaryReader
:
private class StreamWrapper : Stream
{
private readonly Stream baseStream;
public StreamWrapper(Stream baseStream)
{
this.baseStream = baseStream;
}
public override long Length
{
get { /* caching implementation */ }
}
public override long Position
{
get { /* caching implementation */ }
set { /* caching implementation */ }
}
// Override all other Stream virtuals as well
}
Это позволит вам прозрачно использовать StreamWrapper
и сохранить поведение кэширования. Но возникает вопрос: Stream
вы работаете с такой тупостью, что он сам не кеширует это?
А если это не так, возможно, увеличение производительности, которое вы видите, является результатом этого оператора if
внутри ReadBytes
, а не кеширования Length
и Position
?