TFileStream buffer

← →
bns (2005-06-24 15:59) [0]

А отчего размер буфера в TFileStream.WriteBuffer равен 64К? Корректно будет переписать метод и сделать его больше?

Спасибо.

← →
begin...end © (2005-06-24 16:26) [1]

А где в методе WriteBuffer фигурирует 64К?

← →
ferr © (2005-06-24 16:38) [2]

код в студию

← →
bns (2005-06-24 16:54) [3]

function TStream.CopyFrom(Source: TStream; Count: Longint): Longint;
const
MaxBufSize = $F000;
begin

WriteBuffer идет ниже и как раз не может записать больше этих самых $F000.

← →
Eraser © (2005-06-24 16:58) [4]

bns (24.06.05 16:54) [3]
MaxBufSize = $F000;

Откуда выдрал кусок? )

← →
ferr © (2005-06-24 17:04) [5]

Экономим память, не выделять же огромными кусками.
А WriteBuffer тут причём? Это CopyFrom...

← →
begin...end © (2005-06-24 17:05) [6]

> bns (24.06.05 16:54) [3]

> $F000

Это не 64К.

> WriteBuffer идет ниже и как раз не может записать
> больше этих самых $F000.

В реализации самогО WriteBuffer (а именно об этом шла речь в исходном вопросе) ограничений на размер буфера нет. А вот в CopyFrom действительно копирование происходит циклически с указанным размером буфера. Чем не устраивает этот размер?

← →
bns (2005-06-24 17:39) [7]

>Чем не устраивает этот размер?
Хочу увеличить эффективность копирования.

>Это не 64К.
ОК, это меньше. Если я увеличу его, это приведет к каким-либо некорректностям в работе этого кода?

Спасибо.

← →
ferr © (2005-06-24 18:05) [8]

> Если я увеличу его, это приведет к каким-либо
> некорректностям в работе этого кода?

Вам надо ящики из одного места перенести в другое. Вы можете таскать по одному ящику или перевести все сразу.
В одном случае больше памяти надо, а в другом больше времени. Классическая ситуация. Ограничения накладывает система.

← →
bns (2005-06-24 18:31) [9]

Красивая аллегория. Я понял ее так, что увеличение размера буфера к катастрофическим последствиям привести не должно.

> увеличение размера буфера к катастрофическим
> последствиям привести не должно.

Не должно. В данном случае увеличивать не надо.
ИМХО.

> ferr © (24.06.05 18:05) [8]

> Вы можете таскать по одному ящику или перевести все
> сразу.
> В одном случае больше памяти надо, а в другом больше
> времени.

Ну... чтобы перевозить ящики, много памяти не надо... :))

> bns (24.06.05 18:31) [9]

> Я понял ее так, что увеличение размера буфера к
> катастрофическим последствиям привести не должно.

Увеличение размера в разумных пределах (несколько единиц раз) -- вероятно, не должно. Вообще говоря, это зависит от многих факторов. Например: из какого TStream будут копироваться данные методом CopyFrom? Из TMemoryStream небольшого размера, у которого данные уже находятся в памяти, или из TFileStream, который читает данные с диска? Не уверен, но думаю, что, несмотря на кэширование при дисковом чтении, изменение размера буфера окажет большее влияние на скорость копирования в случае TFileStream. Короче говоря, вряд ли здесь могут быть однозначные общие рекомендации. Можно попробовать, сравнить производительность (в конкретных условиях) и сделать выводы, учитывая также и то, что эти конкретные условия, в которых проводился тест, впоследствии могут и измениться.

TFileStream buffer Найти похожие ветки