Чем писать лог?

← →
Б (2009-10-13 17:58) [0]

Здрасти!
Работаю над логом. (Записывать много чего придёться)
Встал выбор: каким образом работать с текстовым файлом.
1 способом, через Pascal"евские - Assign, WriteLn, Reset... (Var File: Text)
2 способом, через Windows"ие - CreateFile, WriteFile... (Var File: LongWord)
Пока выбрал 1-й. (Но что-то, говорят, для логов не пойдёт)
Всё таки: какой способ лучше и быстрее?
А может есть альтернативы?

← →
Игорь Шевченко © (2009-10-13 18:10) [1]

> Но что-то, говорят, для логов не пойдёт

"Говорят, а ты не слушай.
Говорят, а ты не верь"
(с) эстрада

Нормально "идет" для логов

← →
Anatoly Podgoretsky © (2009-10-13 19:04) [2]

Первый значительно удобнее, пока не требуется Юникод.

← →
DVM © (2009-10-13 20:49) [3]

> Первый значительно удобнее,

Самый удобный способ номер 3) - TFileStream

← →
qwer_qwer (2009-10-13 21:03) [4]

> Всё таки: какой способ лучше и быстрее?

Какие твои критерии оценки?
"Лучше" - в чём лучше?
"Быстрее" - что под этим понимать?

← →
Loginov Dmitry © (2009-10-13 22:50) [5]

> Всё таки: какой способ лучше и быстрее?
> А может есть альтернативы?

Для простых случаев пойдет и Assign, WriteLn (без ресетов).

В сложных приложениях приходится наворачивать, делать
синхонизацию записи, автоматическую обрезку либо переименование
файлов лога и т.д. В этом случае можешь использовать ldslogger.
(качается тут: http://matrix.kladovka.net.ru/index.php?page=downloads&categ=other&pagenum=1 )

← →
Rouse_ © (2009-10-14 00:20) [6]

А стандартный лог чем не устраивает?
Создаем свою группу и туда ReportEvent(), по крайней мере проблем с "невозможностью записи" по причине РО на файл лога не возникнет, ну и с синхронизацией заморачиваться не нужно.

← →
Loginov Dmitry © (2009-10-14 00:34) [7]

> А стандартный лог чем не устраивает?

Имхо, для автора это будет сложно. Как-никак отдельная технология, требующая дополнительного изучения.
Начинать нужно с простого (т.е. с текстовых файлов :))

← →
Б (2009-10-17 13:35) [8]

> Нормально "идет" для логов

А тут считают, что нет. ;)
http://www.delphikingdom.com/asp/answer.asp?IDAnswer=73404

← →
Игорь Шевченко © (2009-10-17 13:58) [9]

> А тут считают, что нет. ;)

Пусть себе считают, практика - лучший критерий истины. Впрочем, ты не озвучил требования к своей процедуре логгирования, а без этого детальное обсуждение не имеет смысла.

В том обсуждении критика сводится к тому, что AssignFile/Writeln "морально устарели", я не понимаю подобных аргументов при программировании.

← →
Б (2009-10-17 14:05) [10]

А мессагу от 13-10-2009 01:21 читали?

← →
Б (2009-10-17 14:11) [11]

> Пусть себе считают, практика - лучший критерий истины.

На Королевстве будто люди не опытные сидят? И советуют, что взбредёт в голову.

← →
Б (2009-10-17 14:13) [12]

> Впрочем, ты не озвучил требования к своей процедуре логгирования

А какие могут быть требования?

← →
Игорь Шевченко © (2009-10-17 14:54) [13]

Я к чему: кто хочет простого, пишет простое, кто хочет сложного, пишет сложное.

← →
qwer_qwer (2009-10-17 19:35) [14]

> А мессагу от 13-10-2009 01:21 читали?

А где такая?

← →
qwer_qwer (2009-10-17 19:39) [15]

> > Нормально "идет" для логовА тут считают, что нет. ;)

Что ж ты неправду говоришь?
Там абсолютно нормальное обсуждение возможностей.

Но, как сказал Игорь Шевченко, желающие могут делать сложно.

← →
Жорж (2009-10-17 19:58) [16]

Чем сложнее, тем лучше. От этого очень самооценка поднимается, ну и похвастаться перед коллегами будет чем.

← →
Б (2009-10-17 19:59) [17]

> А где такая?

В ссылке.

> Что ж ты неправду говоришь?

Это вопрос ко мне?
Если да, то почему, я говорю неправду?
Тут сказали, что "Нормально "идет" для логов" - (Writeln/Reset...),
а там TFileStream. Что за вопросы?

← →
Б (2009-10-17 20:03) [18]

> Я к чему: кто хочет простого, пишет простое, кто хочет сложного,
> пишет сложное.

TFileStream - просто, а Reset/ReadLn - сложно? Скорее наоборот.
Да и я только недавно связался с файлами, так что: "От простого к сложному".

← →
Германн © (2009-10-17 20:35) [19]

> Б (17.10.09 19:59) [17]
>
> > Что ж ты неправду говоришь?
>
> Это вопрос ко мне?
> Если да, то почему, я говорю неправду?
> Тут сказали, что "Нормально "идет" для логов" - (Writeln/Reset.
> ..),
> а там TFileStream. Что за вопросы?

По-моему ты плохо читал и там и тут. А если кто-нибудь, когда-нибудь тебе скажет, что один вариант "однозначно" хуже или "однозначно" лучше при такой общей постановке вопроса, то ты больше не играй с ним в одной песочнице.

← →
Б (2009-10-17 20:54) [20]

> По-моему ты плохо читал и там и тут.

Да ну.

> А если кто-нибудь, когда-нибудь тебе скажет, что один вариант
> "однозначно" хуже или "однозначно" лучше при такой общей
> постановке вопроса, то ты больше не играй с ним в одной
> песочнице.

Пройди по ссылке и прочитай хотя бы мессагу от 13-10-2009 01:21 Александра Алексеева, в словах которого я не сомневаюсь.
Вот чем он прорезюмировал своё высказывание:

Боже, вы действительно хотите использовать AssignFile/WriteLn после всего этого?
P.S. Нет, я вполне допускаю, что могут быть ситуации, где их использование будет оптимальным, но они относительно редки. В 95% вам следует предпочесть что-то другое (например, TFileStream).

← →
Германн © (2009-10-17 21:07) [21]

> Боже, вы действительно хотите использовать AssignFile/WriteLn
> после всего этого?
> P.S. Нет, я вполне допускаю, что могут быть ситуации, где
> их использование будет оптимальным

Вот, вот. И я о том же. Только я не берусь делать статистические выкладки для столь общего вопроса как "
> Чем писать лог?
"

← →
Anatoly Podgoretsky © (2009-10-17 21:08) [22]

А я например с ним не согласен, при том строго наоборот 95 в пользу TextFiles и только 6 процентов в особых случаях, речь конечно про TextFiles

← →
Германн © (2009-10-17 21:18) [23]

> Anatoly Podgoretsky © (17.10.09 21:08) [22]

Тем более, что вопрос задан в этой конференции. Где как правило речь может идти лишь о несложных приложениях.

← →
Б (2009-10-17 21:19) [24]

> Только я не берусь делать статистические выкладки для столь
> общего вопроса как > Чем писать лог?

Назови тогда уж ещё несколько способов "чем писать лог" кроме 3-х:
1) Writeln/Readln.
2) CreateFile/CloseHandle.
3) TFileStream. (Обёртка под 2 пункт)

Мне доходчиво объяснили, что 3-й способ лучше 1-го.
Можешь поэтому поводу что-то сказать?

> А я например с ним не согласен

Отпишитесь на Королевстве. ;)

← →
Германн © (2009-10-17 21:31) [25]

> Мне доходчиво объяснили, что 3-й способ лучше 1-го.
> Можешь поэтому поводу что-то сказать?
>

А зачем для этого мне что-то ещё говорить? Я полностью согласен вот с этим
> P.S. Нет, я вполне допускаю, что могут быть ситуации, где
> их использование будет оптимальным
Ты не тем сейчас занимаешься. Если ты
> только недавно связался с файлами, так что: "От простого
> к сложному".

так и иди этим путем. Освой сначала простое (но как следует освой), затем переходи к более сложному. А там и сам авось поймешь, что все имеющиеся варианты работы с файлами имеют свое право на жизнь.

← →
Германн © (2009-10-17 21:39) [26]

> Назови тогда уж ещё несколько способов "чем писать лог"
> кроме 3-х:

По крайней мере ещё один вариант часто упоминается в конференции "WinAPI". Но чтобы его понять надо выучить очень много "ругательных" слов, которые при этом произносят _Rouse, ИШ и др. и пр.
:)

← →
Anatoly Podgoretsky © (2009-10-17 22:26) [27]

> Б (17.10.2009 21:19:24) [24]

> Мне доходчиво объяснили, что 3-й способ лучше 1-го.
> Можешь поэтому поводу что-то сказать?

В подобных случаях смысла нет.

← →
Игорь Шевченко © (2009-10-17 23:16) [28]

Автор, ты что протоколировать собрался ?

← →
qwer_qwer (2009-10-18 01:30) [29]

> Б (17.10.09 20:54) [20]
> > По-моему ты плохо читал и там и тут. Да ну.> А если кто-
> нибудь, когда-нибудь тебе скажет, что один вариант > "однозначно"
> хуже или "однозначно" лучше при такой общей > постановке
> вопроса, то ты больше не играй с ним в одной > песочнице.
> Пройди по ссылке и прочитай хотя бы мессагу от 13-10-2009
> 01:21 Александра Алексеева, в словах которого я не сомневаюсь.
> Вот чем он прорезюмировал своё высказывание:Боже, вы действительно
> хотите использовать AssignFile/WriteLn после всего этого?
> P.S. Нет, я вполне допускаю, что могут быть ситуации, где
> их использование будет оптимальным, но они относительно
> редки. В 95% вам следует предпочесть что-то другое (например,
> TFileStream).

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

> Отпишитесь на Королевстве. ;)

А зачем кто-то будет там отписываться?

Да, единственное преимущество старого способа доступа (AssignFile/WriteLn) - поддержка форматирования. Т.е. вы можете написать:

WriteLn("The X = ", X);

На этом преимущества заканчиваются и начинаются недостатки.

Преимущества перед чем? Перед всеми остальными методами?

Во-первых, для AssignFile/WriteLn есть возможность отключить исключения и анализировать IOResult. Хотя на первый взгляд это кажется удобством, на самом деле это чаще всего становится источником ошибок.

А зачем отключать исключения? Их обрабатывать надо, а не отключать. В этом случае они будут не менее информативны, чем при использовании других методов.

Во-вторых, в сообщениях ошибок от Reset/Append/Rewrite отсутствует имя файла. Т.е. когда вы получаете ошибку в программе, то она вообще ничего вам не говорит в чём же конкретно затык. Сообщения от TFileStream более подробны. Это опять тяжёлое наследие Паскаля.

Можно привести примеры сообщений об ошибках в обоих случаях, которые подтверждали бы это?

В-третьих, WriteLn работает с текстовым буфером. Это значит, что все данные идут по такому маршруту: диск <-> системный буфер <-> буфер TTextRec <-> ваш код.
Это может и имело смысл энцать лет назад во времена DOS и Паскаля (когда не было адекватного кэширования диска), но сейчас это только лишние накладные расходы.

Возможно и есть накладные расходы. В единственном месте - системный буфер <-> буфер TTextRec

В-четвёртых, вы не можете указывать подробно флаги открытия файлов. Например, для того же TFileStream можно передать в конструктор дескриптор от CreateFile, указывая, скажем, FILE_FLAG_DELETE_ON_CLOSE (например, для этого) или FILE_FLAG_SEQUENTIAL_SCAN. Это довольно здорово увеличит скорость вашей работы, если ваши операции подходят под эти опции.

Это автор сообщения говорит про работу с протоколом работы?
Что-то мне говорит, что это выстрел в воздух - об этих опциях можно было даже не говорить в рамках стоящей задачи - не для того они предназначены.

В-пятых, вы не можете надёжно указать режим открытия и блокировок файла. Да, у вас есть FileMode, но она не потокобезопасна. Опять же, это имело смысл во времена DOS, когда система была однозадачной. Сейчас это только источник багов.

В рамках поставленной задачи - бред.

В-шестых, как уже упоминали ниже, у AssignFile/WriteLn есть проблема с действительно большими файлами.

Автор это из пальца высосал?
Вопрос - какого размера планируется писать протоколы?

Единственное преимущество WriteLn по форматированию текста легко перекрывается Format. Более того, именно этот способ (вкупе с переносом текстовых констант в resourcestring или const) является правильным с точки зрения локализации.

Использование Format никак не отвергает использования WriteLn. Более того - это более удобно.
То же самое и про локализацию.

Боже, вы действительно хотите использовать AssignFile/WriteLn после всего этого?

Конечно, ведь автор высосал ис пальца аргументы и навязывает своё "единственно правильное видение".

← →
Германн © (2009-10-18 01:58) [30]

> qwer_qwer (18.10.09 01:30) [29]

Имхо, зря ты это писал. Зря стирал подушечки своих пальцев и символы на клавишах своей клавиатуры.
Автор сабжа этого пока не поймёт. Он пока "в песочнице". И авторов ответов он ищет тоже в той же песочнице.
Тут достаточно лишь прочитать сам сабж "
> Чем писать лог? [D7, XP]
>
> Б (13.10.09 17:58)
>
> Здрасти!
> Работаю над логом. (Записывать много чего придёться)
> Встал выбор: каким образом работать с текстовым файлом.
> 1 способом, через Pascal"евские - Assign, WriteLn, Reset.
> .. (Var File: Text)
> 2 способом, через Windows"ие - CreateFile, WriteFile...
> (Var File: LongWord)
> Пока выбрал 1-й. (Но что-то, говорят, для логов не пойдёт)
> Всё таки: какой способ лучше и быстрее?
> А может есть альтернативы?

Но авторов ответов он выбирает из той же песочницы. Которые не отвечают на сам сабж, но отвечают на свои собственные мысли по некоему вопросу, причём уверенно, приводя некие доводы. Вот только сам вопрос автором сабжа сформулирован настолько обще и непонятно, что ответить можно практически всё что угодно.
Уф. Высказался.

← →
qwer_qwer (2009-10-18 13:53) [31]

> Но авторов ответов он выбирает из той же песочницы. Которые
> не отвечают на сам сабж, но отвечают на свои собственные
> мысли по некоему вопросу, причём уверенно, приводя некие
> доводы. Вот только сам вопрос автором сабжа сформулирован
> настолько обще и непонятно, что ответить можно практически
> всё что угодно.Уф. Высказался.

Ну почему. Автор вполне логично верит авторитетам на Королевстве Делфи.
Просто пока не относится критически к высказываниям.

← →
Юрий Зотов © (2009-10-18 13:58) [32]

> автор

Вы не на том заостряете внимание. Думать надо над тем, ЧТО писать в лог, а не о том КАК в него писать.

← →
DVM © (2009-10-18 14:24) [33]

> qwer_qwer (18.10.09 01:30) [29]

> На этом преимущества заканчиваются и начинаются недостатки.
> Преимущества перед чем? Перед всеми остальными методами?

Вот именно, это даже не преимущество. Так что преимуществ у паскалевских методов работы с файлами нет вообще. Анахронизм это.

> А зачем отключать исключения? Их обрабатывать надо, а не
> отключать. В этом случае они будут не менее информативны,
> чем при использовании других методов.

Ну обработай мне исключение, которое возникает при доступе паскалевской функции к дисководу в котором нет диска. Или когда отсутствуют права на доступ к файлу, или ... эти или можно продолжать бесконечно и во всех случаях толковой информации о том что же произошло от этих функций не получишь. Хошь обрбатывай, хошь не обрабатывай.

> Возможно и есть накладные расходы. В единственном месте
> - системный буфер <-> буфер TTextRec

Попробуй писать очень интенсивно и много - разница налицо.

> В-пятых, вы не можете надёжно указать режим открытия и блокировок
> файла. Да, у вас есть FileMode, но она не потокобезопасна.
> Опять же, это имело смысл во времена DOS, когда система
> была однозадачной. Сейчас это только источник багов.
>
>
> В рамках поставленной задачи - бред.

Задачи никакой не ставилось. А потокобезопасный лог - сплошь и рядом треуется.

> Вопрос - какого размера планируется писать протоколы?

Такого, какого позволяет файловая система, не меньше.

← →
qwer_qwer (2009-10-18 14:53) [34]

> Вот именно, это даже не преимущество. Так что преимуществ
> у паскалевских методов работы с файлами нет вообще. Анахронизм
> это.

Если это не преимущество и недостаток, тогда зачем это упоминать? Для красного словца? Вообще-то на этих форумах технические специалисты, а не гуманитарии с любовью к красивым словам.

> Ну обработай мне исключение, которое возникает при доступе
> паскалевской функции к дисководу в котором нет диска. Или
> когда отсутствуют права на доступ к файлу, или ... эти или
> можно продолжать бесконечно и во всех случаях толковой информации
> о том что же произошло от этих функций не получишь. Хошь
> обрбатывай, хошь не обрабатывай.

Пожалуйста. В чём проблема-то? В неумении?

procedure TForm1.Button1Click(Sender: TObject); var f: TextFile; begin try AssignFile(f,"a:\1.txt"); Reset(f); CloseFIle(f); except on E: EInOutError do ShowMessage("Îøèáêà "+IntToStr(E.ErrorCode)+":"+E.Message+ "("+SysErrorMessage(GetLastError)+"/"+SysErrorMessage(E.ErrorCode)+")"); end; end;

> Попробуй писать очень интенсивно и много - разница налицо.

Вряд ли. Где тесты на сравнение и результаты?

> Задачи никакой не ставилось. А потокобезопасный лог - сплошь
> и рядом треуется.

Вот когда он потребуется, тогда и потребуется отдельное обсуждение для конкретной задачи.

> Такого, какого позволяет файловая система, не меньше.

А если точнее? В Мб,Гб, Тб?

← →
qwer_qwer (2009-10-18 14:55) [35]

Особенно красиво звучит ничем не обоснованное -

> можно продолжать бесконечно и во всех случаях толковой информации
> о том что же произошло от этих функций не получишь.

← →
Плохиш © (2009-10-18 15:13) [36]

> qwer_qwer (18.10.09 14:53) [34]

> Вообще-то на этих форумах технические специалисты, а не
> гуманитарии с любовью к красивым словам

Экма :-) "наивный чукотский мальчик" :-))

← →
DVM © (2009-10-18 15:14) [37]

> qwer_qwer (18.10.09 14:53) [34]

> Если это не преимущество и недостаток, тогда зачем это упоминать?
> Для красного словца?

Я не упоминал.

> Пожалуйста. В чём проблема-то? В неумении?

Да насчет отсутствующего диска я погорячился, но хорошо, вот другой пример, файл c:\1.txt имеет атрибут только чтение (или нет доступа со стороны файловой системы)
Твой код:

] procedure TForm1.btn1Click(Sender: TObject); var f: TextFile; begin try AssignFile(f,"c:\1.txt"); Reset(f); write(f, "test"); CloseFIle(f); except on E: EInOutError do ShowMessage("Error: "+IntToStr(E.ErrorCode)+":"+E.Message+ "("+SysErrorMessage(GetLastError)+"/"+SysErrorMessage(E.ErrorCode)+")"); end; end;

Выдает:

---------------------------
Project1
---------------------------
Error: 105:I/O error 105(Операция успешно завершена/Этот семафор более не принадлежит использовавшему его процессу)
---------------------------
OK
---------------------------

Ерунда какая то.

Правильный код на TFileStream:

procedure TForm1.btn2Click(Sender: TObject); var Stream: TFileStream; s: string; begin s := "test"; Stream := TFileStream.Create("c:\1.txt", fmOpenWrite); try Stream.Write(s[1], Length(s) * SizeOf(Char)); finally Stream.Free; end; end;

выдает

---------------------------
Project1
---------------------------
Cannot open file "c:\1.txt". Отказано в доступе.
---------------------------
ОК
---------------------------

> Вряд ли. Где тесты на сравнение и результаты?

Без проблем щас организуем.

> Выдает:
>
> ---------------------------
> Project1
> ---------------------------
> Error: 105:I/O error 105(Операция успешно завершена/Этот
> семафор более не принадлежит использовавшему его процессу)
> ---------------------------
> OK
> ---------------------------
>
> Ерунда какая то.

Хотя нет, извиняюсь, не заметил что в твоем коде Reset(f); а не Rewrite;

>
> > Вряд ли. Где тесты на сравнение и результаты?
>
> Без проблем щас организуем.

Провел сравнительное тестирование TextFile/Writeln , TFileStream и Windows.WriteFile.

Результаты оказались довольно неожиданными для меня.
Writeln почти в 2 раза обгоняет Windows.WriteFile и соответственно TFileStream.
Самое удивительное, что Writeln сводится к той же Windows.WriteFile

Так что насчет скорости я был не прав.

← →
Sapersky (2009-10-18 16:20) [40]

WriteLn буферизованный. Если ещё буфер задать 2-4 кб вместо стандартных 128 байт (SetTextBuf), будет ещё быстрее.
Я в той ветке на Королевстве выкладывал результат сравнения буферизованного (хотя и не конкретно WriteLn) и небуферизованного методов - разница в 3.5 раза.

> Sapersky (18.10.09 16:20) [40]
>
> WriteLn буферизованный.

Да, так и есть. Если писать довольно большими кусками он начинает чуть отставать от Windows.WriteFile

Для лога, я считаю, гораздо удобнее в ряде случаев использовать не буферизованный ввод/вывод, а закрытие файла после каждой записи. В этом случае удобно а) смотреть лог работающей программы б) в случае ошибки в программе все данные лога будут на диске (а не в текстовом буфере), что в ряде случаев упрощает диагностику.

Кстати, конструкция

AssignFile(F, "foo");
if FileExists("foo") then
Append(F)
else
Rewrite(F);

Лмается на файлах больше двух гигагбайт. Но я не пишу логи в несколько гигабайт - уж больно с ними потом неудобно работать :)

для отладки использую
unit ROMLog; interface uses Windows, SysUtils; function AppendLog(const AMsg: string): Boolean; var _csROMLog: TRTLCriticalSection; implementation function AppendLog(const AMsg: string): Boolean; var fText: TextFile; sFileName, sText: string; begin Result := False; try sFileName := IncludeTrailingPathDelimiter(ExtractFilePath(ParamStr(0))); if not DirectoryExists(sFileName + "Logs") then MkDir(sFileName + "Logs"); sFileName := sFileName + "Logs\" + FormatDateTime("yyyy_mm", Now) + "_rom_log.txt"; except Exit; end; EnterCriticalSection(_csROMLog); try AssignFile(fText, sFileName); if FileExists(sFileName) then Append(fText) else Rewrite(fText); try sText := FormatDateTime("dd-mm-yyyy_hh:nn:ss", Now) + "#T:" + AMsg; Writeln(fText, sText); finally CloseFile(fText); end; Result := True; finally LeaveCriticalSection(_csROMLog); end; end; initialization InitializeCriticalSection(_csROMLog); finalization DeleteCriticalSection(_csROMLog); end.

если лог нужен для функционала, то лучше использовать другой подход.

> Игорь Шевченко © (18.10.09 19:00) [42]

> Для лога, я считаю, гораздо удобнее в ряде случаев использовать
> не буферизованный ввод/вывод, а закрытие файла после каждой
> записи

Только у этого способа есть один недостаток - уж слишком сильно замедляет программу при интенсивном логгировании.

DVM © (18.10.09 20:42) [44]

Как ты понимаешь - кому что надо, кому надо подробный лог для диагностики (а для чего еще лог нужен?), кому надо быстро. Для "быстрого" протоколирования мы использовали отдельный процесс, которому посылали сообщения о необходимости занесения в протокол тех или иных данных, натурально, у этого процесса был достаточный буфер, чтобы он не захлебывался при приеме сообщений с достаточно интенсивной скоростью, разумеется, было управление файлами, чтобы текущий протокол по достижении нужного размера/количества записей отключался и сбрасывался в базу данных/архив, а запись при этом велась в другой файл, ну и так далее.

Только сложно это - мы использовали для протоколирования работы нескольких связанных процессов, Event log нам не понравился, уж больно неудобно делать его пост-обработку.

> DVM © (18.10.09 16:06) [39]

> Writeln почти в 2 раза обгоняет Windows.WriteFile и соответственно
> TFileStream.

У тебя тесты какие-то неправильные.

--
Regards, LVT.

> Leonid Troyanovsky © (18.10.09 23:46) [46]

> У тебя тесты какие-то неправильные.

Может поделишься правильными? И мы поучимся.

> Может поделишься правильными?
лучше "правильным" компьютером с новыми дисками которым программная буферизация только мешает... (адрес для "дележки" в личку ;о) )

> DVM © (19.10.09 00:47) [47]

> > У тебя тесты какие-то неправильные.

> Может поделишься правильными?

Ну, ты ж сам все правильно объяснил.
Внизу лежит WriteFile, сверху - overhead.
Там же еще парсинг строк и т.п.

Сравнивать можно, скажем, WriteFile vs memory mapped file,
хотя, наверное, и это мну не очень интересно.

Проще, наверное, если б ты показал сравнения
(у тебя, IMHO, д.б. где-то под рукой),
а мы постараемся найти огрех.

--
Regards, LVT.

> Leonid Troyanovsky © (19.10.09 18:58) [49]

> а мы постараемся найти огрех.

Да нет там огреха. Понятно, что я сравнивал "просто Writeln" с "просто WriteFile" и TFileStream.Write(). Только вот "просто Writeln" оказался "просто буферизованный Writeln".

Большинство ведь и не догадываются о том, что Writeln использует хитрую буферизацию и внутренности Writeln как правило мало кем изучаются и Writeln рассматривается как нечто совсем простое как 2 копейки. Ан нет оказывается, Writeln не так прост. Я вот сам заблуждался.

Очевидно, что если организовать/задействовать буферизацию WriteFile/TFileStream то как минимум они сравняются.

> DVM © (19.10.09 20:17) [50]

> Да нет там огреха.

> Очевидно, что если организовать/задействовать буферизацию
> WriteFile/TFileStream то как минимум

Дык, тут и огрех, чего у ж там далее.
Сравнивать стоит сопоставимое.

> задействовать буферизацию WriteFile/TFileStream то как минимум

Ясенное дело, что сравняются "как минимум", бо выше - overhead.

--
Regards, LVT.

> DVM (19.10.2009 20:17:50) [50]

Writeln ой как не просто, начнем с того, что нет процедуры Writeln, это компьютерная магия.

Кроме того зачем сравнивать низкоуровневый вывод с высокоуровневым, когда за сценой ой как много чего справлено, избавляя от необходимости думать об преобразованиях. Можно сравнивать например с Бейсиком или некоторыми другими языками, которые имеют встроеные средства ввода/вывода.

WriteLn(F, Integer, Float, Boolean, DateTime, string) и все это одновременно в одном вызове без необходимости преобразования в текстовый формат, плюс есть и небольшие возможности форматирования вывода, что не мешает внешнему форматированию. Плюс еще и буферизация и возможность расширения.

Но есть некоторые ограничения, по режимам открытия файла, по Юникоду, ведь "функции" более 30 лет.

Начиная с "DVM © (18.10.09 14:24) [33]"
начался холивар, который продолжил холивар на Королевстве, и которого так жаждал автор сабжа.
Ну почему-бы автору не задать сей вопрос на www.sources.ru? Там к холиварам вроде нормально относятся.

Чем писать лог? Найти похожие ветки