On Mon, Sep 26, 2005 at 09:08:24AM +0400, Artem Chuprina wrote:
> Timur V. Elzhov -> debian-russian@lists.debian.org @ Sun, 25 Sep 2005
> 20:28:04 +0400:
>
> TVE> Мне нужно на Perl сделать что-то вроде cat, то есть читать бинарные
> TVE> данные и записывать куда-нибудь. Данных может быть очень много,
> TVE> поэтому записать их все в память, а потом записать на диск не получится.
> TVE> Делаю следующее:
>
> TVE> syswrite OUT, $str while (sysread SRC, $str, 1_000_000);
>
> TVE> если OUT сделать псевдонимом STDOUT и шеллом перенаправить этот STDOUT
> TVE> в файл, то это работает раз в шесть-семь (!) быстрее, чем когда я явно
> TVE> открываю OUT через open(). Почему? Я неправильно выбрал размер LENGTH
> TVE> в sysread? Вообще, как наиболее эффективно организовать прямую передачу
> TVE> данных в Perl?
>
> Вообще-то буферизованный вывод в perl делается через read/print, а не
> через sysread/syswrite. Но вот насчет "в частности" неочевидно. Разве
> что после каждого syswrite делается fsync? Да вроде не
> должно... Может, конечно, артефакт того, что открывается через open()
> (для sys* надо и открывать через sysopen), но такая возможность тоже
> больше похожа на чисто теоретическую, а проверять лениво.
Я вообще-то подозреваю, что sysread/syswrite -- это интерфейс к read(2)
& write(2). Почти никакой буферизации при этом нет (буферизация может
быть на уровне ядра, но пользователю это обычно неинтересно).
fsync(3) имеет смысл только для потоков полученных fopen(3).
Что же касается скорости работы, читать/писать по мегабайту -- не самый
комфортный для ядра режим. Неудивительно, что когда вы через shell'овское
перенаправление включаете libc'шную буферизацию, всё начинает работать
лучше.
Видимо, следует повторить рекомендацию пользоваться буферизацией из libc,
а не изобретать велосипед самостоятельно. Для этого, как уже сказано,
в perl стоит использовать read/print.
--
Regards,
Sasha.
Alexandra N. Kossovsky, software engineer.
e-mail: [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
