Что быстрее - двоичный или текстовый файл?

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

Теперь я думаю, что мой преподаватель ошибался.. или нет?

0

Сообщение от taras atavin С бинарным форматом могут не совпасть особенности процессора

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

Добавлено через 3 минуты

Сообщение от taras atavin Это если ты делаешь саму файловую систему или операционную систему.

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

0

Сообщение от DrOffset Оценить скорость - это нужно учитывать в любом случае. Вопрос же про скорость был, да? Так вот с точки зрения файловой системе скорость одинаковая.

С точки зрения файловой системы не скорость одинаковая, а нет самого признака, а текстовым, или бинарным бывает формат файла.

0

Сообщение от taras atavin С точки зрения файловой системы не скорость одинаковая, а нет самого признака.

Я об этом и писал, нет?
Вот.

Добавлено через 9 минут

Сообщение от taras atavin а текстовым, или бинарным бывает формат файла.

Естественно, только понятие файл тут уже вторично. Об этом и был мой пост по ссылке. Но вопрос в теме звучал именно как текстовый или бинарный - файл. Когда правильно было бы текстовый или бинарный формат, т.к. у файла без знания формата не может быть такой характеристики как текстовый или бинарный, ты сам только что это сказал. Об этом и я все время говорил. И пресловутая замена \n на \n\r - это тоже часть формата, просто немного более низкого уровня, принятого в данной системе.

0

Сообщение от DrOffset у файла без знания формата не может быть такой характеристики как текстовый или бинарный, ты сам только что это сказал.

Это с точки зрения файловой системы, но ведь предполагается, что этот признак есть, значит речь не о ней, а программе, с точки зрения которой любой файл всегда какого либо формата.

0

Сообщение от taras atavin а программе, с точки зрения которой любой файл всегда какого либо формата.

Конечно. Это никак не противоречит ничему из того, что здесь было написано.
Тут скорее играет роль каким образом был поставлен изначальный вопрос, и в рамках каких категорий мы должны оперировать. Т.к. это не было уточнено, то вот мы и обратились к самым общим категориям, которые были.
Для сравнения, если взять файл в UNIX, который связан с последовательным портом, то чтение/запись туда всегда будут последовательны в силу его природы.

0

Сообщение от DrOffset Для сравнения, если взять файл в UNIX, который связан с последовательным портом, то чтение/запись туда всегда будут последовательны в силу его природы.

Ну да, конечно. Если работаешь с файлом последовательно, то уж ни как не произвольно. А если открыть по-другому? В контексте выбора даже категории формата потоки - не препятствие.

Добавлено через 34 минуты

Сообщение от DrOffset Еще раз, пройди по ссылке и узри, что бинарных форматов - тысячи.

Думаешь, я не в курсе?

Сообщение от DrOffset А сохранение памяти как она есть на диск - это только маленький частный случай, про подводные камни которого все знают

Значит не все, раз объяснять приходится.

Добавлено через 12 минут

Сообщение от DrOffset И пресловутая замена \n на \n\r - это тоже часть формата, просто немного более низкого уровня, принятого в данной системе.

Только процессору плевать на то, как ты представишь перевод строки, это вкусы приложений: одно выполняет обнуление абсциссы и приращение ординаты под одним кейсом на \n, для другого это две раздельные реакции на два разных управляющих символа. Соответственно для них файл перекодируется перед отправкой другому юзверю. К чтению файла с диска это не относится. Файл же формата, например, .bmp отправляют, как есть, без переворота слов на любую платформу, но прочитанные из него числовые данные должны обрабатываться АЛУ процессора, которое может работать со словами задом на перёд. И тогда уже придётся переворачивать слова при каждом чтении/записи. Файл при этом остаётся .bmp, порядок байт на диске остаётся прежним, но в памяти он должен быть всегда противоположным. К задаче копирования самого файла с раскладкой копий по десяти каталогам это не относится, в этом случае файл читается и пишется, как сырой. Но если его читает приложение, то оно не должно искажать, например, ширину растра.

Сообщение от DrOffset Наконец-то ты понял

, что именно тебе не понятно.

0

Сообщение от taras atavin Значит не все, раз объяснять приходится.

Я не знаю зачем ты мне это объясняешь Я вроде не давал повода сомневаться.

Сообщение от taras atavin Кликните здесь для просмотра всего текста Только процессору плевать на то, как ты представишь перевод строки, это вкусы приложений: одно выполняет обнуление абсциссы и приращение ординаты под одним кейсом на \n, для другого это две раздельные реакции на два разных управляющих символа. Соответственно для них файл перекодируется перед отправкой другому юзверю. К чтению файла с диска это не относится. Файл же формата, например, .bmp отправляют, как есть, без переворота слов на любую платформу, но прочитанные из него числовые данные должны обрабатываться АЛУ процессора, которое может работать со словами задом на перёд. И тогда уже придётся переворачивать слова при каждом чтении/записи. Файл при этом остаётся .bmp, порядок байт на диске остаётся прежним, но в памяти он должен быть всегда противоположным. К задаче копирования самого файла с раскладкой копий по десяти каталогам это не относится, в этом случае файл читается и пишется, как сырой. Но если его читает приложение, то оно не должно искажать, например, ширину растра.

И? Сериализацию как раз и придумали, чтобы уйти от этих проблем. Что ты заладил с этим процессором? Давай я тебе прямо скажу - я все это знаю, причем не по-наслышке, т.к у меня только сейчас проекты работают на 5ти разных аппаратных платформах (не говоря уже об ОС, которых сильно больше).
Давай я напомню твои слова:

Сообщение от taras atavin Кликните здесь для просмотра всего текста Текстовый файл медленнее по другой причине. Как задаётся место в текстовом файле при произвольном доступе? Номерами символа и строки. Но строки имеют разную длину и чтоб найти, где нужная строка находится, надо последовательно прочитать и проанализировать файл от начала. Положение в бинарнике задаётся номером байта, все байты одинаковы, это позволяет вычислить, где конкретно нужный байт находится и сразу перейти к этому месту. С другой стороны, текстовый файл - байтовый. А бинарный? Бинарный может состоять из чего угодно и иметь чёрт знает какое выравнивание, иметь какой угодно порядок байт в словах, двойных словах, четверных словах..., что придётся учитывать при последовательном чтении. Возможно, придётся менять порядок байтов, менять выравнивание, или читать каждое данное отдельно. Все эти дополнительные операции замедляют чтение, но нужны не всегда. При последовательном же чтении текстового файла можно читать блок, что даёт максимальную скорость доступа. Возможно бинарник получится читать также, а может и нет.

На что я только уточнил, что все вышеописанное относится в первую очередь к формату, а не к файлу. С чем ты потом благополучно согласился:

Сообщение от taras atavin а текстовым, или бинарным бывает формат файла.

Ну и в чем смысл твоих дальнейших возражений?

Сообщение от taras atavin Ну да, конечно. Если работаешь с файлом последовательно, то уж ни как не произвольно. А если открыть по-другому? В контексте выбора даже категории формата потоки - не препятствие.

Каким образом, простите? Я этой фразой намекал, что в определенных терминологических рамках понятие файл несколько более широкое, чем область на диске, и у некоторых типов таких файлов о произвольном доступе можно забыть.

0

Сообщение от DrOffset Давай я тебе прямо скажу - я все это знаю, причем не по-наслышке, т.к у меня только сейчас проекты работают на 5ти разных аппаратных платформах

Можно написать ещё больше проектов для 15-ти платформ и только потом догадаться, что возня с заменой \n на \r\n сразу при загрузке текстовика - лишь частный случай поддержки одновременно \n и \n\r в одном приложении, а не обязательная операция на винде и сравнить это со своими проектами, преобразующими при каждой загрузке бинарные данные, а можно о том же самом догадаться на втором проекте, не вылезая за границу одной платформы. Я вот сейчас как раз делаю одновременную поддержку \n, \r\n и \n\r в одном приложении и даже в перемешку в одном файле и обошёлся без замены. И хоть я и прикрутил сразу к загрузке приведение utf8 к многобайтной кодировке, но ведь можно было юзать utf8 и во внутреннем представлении, так что это проблема не формата. Я вообще толкую не о проблемах многоплатформенных бинарников, а об отличии текстовых форматов в контексте перекодирования от бинарных, о том, что в случае текстового формата можно в не перекодировать при чтении на любой платформе и при любых кодировке и фактическом формате и что это не совпадает с бинарником.

0

Сообщение от taras atavin лишь частный случай поддержки одновременно \n и \n\r в одном приложении, а не обязательная операция на винде

Где я написал-то такое?
Я тебе ссылку на дал на справку по fopen, где буржуйским по белому написано, что открытие файла в текстовом режиме может повлечь за собой определенные трансформации последовательности, частным случаем которых является замена \n и \n\r, которую делает некоторое виндовое файловое API.

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

0

Сообщение от DrOffset оследовательности, частным случаем которых является замена \n и \n\r, которую делает некоторое виндовое файловое API.

То то на дебаге просто \n после загрузки текстового файла.

0

Сообщение от taras atavin То то на дебаге просто \n после загрузки текстового файла.

Сразу бы сказал, что не знаешь откуда ноги растут, вот читай.

The C programming language provides the escape sequences '\n' (newline) and '\r' (carriage return). However, these are not required to be equivalent to the ASCII LF and CR control characters. The C standard only guarantees two things: Each of these escape sequences maps to a unique implementation-defined number that can be stored in a single char value. When writing a file in text mode, '\n' is transparently translated to the native newline sequence used by the system, which may be longer than one character. When reading in text mode, the native newline sequence is translated back to '\n'. In binary mode, no translation is performed, and the internal representation produced by '\n' is output directly.

0

И он ещё говорит, что я не знаю, откуда что растёт. Где в абзаце о преобразовании хоть одно упоминание \r?

0

Сообщение от taras atavin И он ещё говорит, что я не знаю, откуда что растёт. Где в абзаце о преобразовании хоть одно упоминание \r?

А зачем в общем абзаце нужно упоминание частного случая?

Достаточно того, что там написано вот это:

When writing a file in text mode, '\n' is transparently translated to the native newline sequence used by the system, which may be longer than one character. When reading in text mode, the native newline sequence is translated back to '\n'. In binary mode, no translation is performed, and the internal representation produced by '\n' is output directly.

Что дословно означает, что последовательность символов для замены может быть больше чем один символ. Что полностью соответствует частному случаю с \r\n.

Ты с чем споришь-то? Сформулируй предмет спора, пожалуйста.
А то сейчас получается, что ты не согласен с тем, что такая замена может происходить? Ну так это нонсенс, я тебе уже два источника привел в подтверждение. Можно посоветовать третий - hex-редактор.
Или с тем, что такая замена относится к формату файла? Ну так ты же сам ранее согласился, что текстовый или не текстовый - это формат. О чем-то другом речи не было.

Так вот, еще раз, с чем ты споришь?

0

Сообщение от DrOffset Что полностью соответствует частному случаю с \r\n.

Оно может и соответствует, но абсолютно не следует.

Добавлено через 1 минуту

Сообщение от DrOffset Ты с чем споришь-то? Сформулируй предмет спора, пожалуйста.

Эйси.
1. Ноги замены на \n\r растут совершенно из другого места.
2. Винда даже не пытается навязать какую либо замену символов, тем более сразу же в операции чтения файла, а позволяет читать текстовые файлы функцией чтения сырых блоков и возлагать их интерпретацию целиком на само приложение.

0

Сообщение от taras atavin Ноги замены на \n\r растут совершенно из другого места.

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

Сообщение от taras atavin Винда даже не пытается навязать какую либо замену символов

Что за манера искажать формулировки?

Я вообще-то нигде не писал слов "навязать", "заставить" и других таких же, тем более того, что целая система себе такое позволяет. Я писал, что некоторое файловое API может проводить такую замену автоматически и что эта замена относится к формату файла. И привел пример частного случая, который можно наблюдать на винде. Чтобы его пронаблюдать нужно буквально сделать следующее: Открыть файл на запись функцией fopen в текстовом режиме, записать некий текст через fwrite с \n, закрыть файл. Открыть файл в hex-редакторе и убедиться в наличии там символа \r.
Можешь сам попробовать, вот код:

0