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

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

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

0

На самом деле операции ввода-вывода выполняются через буфер.
Поэтому разница почти незаметна.

0

Потоки не использовать. С-шные функции намного быстрее работают.

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

Сообщение от nexen Встал вопрос о времени чтения данных с диска,

Можно мапировать файл. Тогда совсем быстро будет.

1

zss, "разница не заметна" - какая разница имеется в виду? И кто в этой разнице выигрывает? Кто быстрее то?
alsav22, вопрос в том, кто быстрее, а не что использовать :0

0

Если говорить абстрактно, то с т.з. именно ввода-вывода никакой разницы вообще нет.
Однако если вернуться к практике, то открытие файла в текстовом режиме может повлечь за собой дополнительные операции, например замена \n на \n\r в windows.
Справка по fopen как раз обо всем этом говорит:

Depending on the environment where the application runs, some special character conversion may occur in input/output operations in text mode to adapt them to a system-specific text file format. Although on some environments no conversions occur and both text files and binary files are treated the same way, using the appropriate mode improves portability.

Если же под текстовыми файлами имелись в виду текстовые или бинарные форматы. То сохранение данных в бинарном формате естественно быстрее. Потому что представление данных в текстовом формате во-первых избыточно, во-вторых требует дополнительных преобразований данных (например число->строка).

1

nexen, данные из себя что представляют?

0

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

Чушь!

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

Сообщение от nexen мой преподаватель ошибался.. или нет?

Возможно, вы неправильно друг друга поняли.

2

Байт, вот примерно такого ответа я и хотел.
Да нет, четко сказано было, что один выигрывает в одном случае, другой в другом. Всю мою детскую психику испортило эта "истина" от преподавателя :/

0

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

0

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

Очего и вопрос был:

Сообщение от alsav22 nexen, данные из себя что представляют?

0

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

Так ведь дело в том, что все что ты описал тоже ограничения "прикладного фактического формата". Т.к. файловой системе все равно какие данные хранить. А всякие выравнивания и количества байт появляются уже потом - с появлением фактического формата. Точно так же как и в текстовых форматах может существовать (xml, etc.), а может и не существовать (plain text) разметка.
Пора бы уже определиться в таком случае что мы считаем файлом. Мой пост рассматривал файл с т.з. файлового API - справка по fopen полностью соответствует моим словам.

0

Сообщение от DrOffset Так ведь дело в том, что все что ты описал тоже ограничения "прикладного фактического формата".

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

Добавлено через 53 секунды

Сообщение от DrOffset Пора бы уже определиться в таком случае что мы считаем файлом.

файл есть наименьшая именованная часть диска.

0

Сообщение от taras atavin В случае бинарника всё перечисленное входит в операции чтения/записи и необходимо для того, чтоб подружить разные процессоры

Мне кажется ты слишком узко понимаешь бинарную сериализацию.
Файловой системе все равно какие данные хранить. Она не делает различия текстовый файл или бинарный, само по себе разделение на текстовый и бинарный условно и служит целям "прикладного фактического формата". Любой текстовый файл является бинарным в понимании файловой системы. Соответственно с т.з. файлового API единственная разница в реализации операций ввода-вывода, может быть только в пресловутых "some special character conversions". А с т.з. файловой ситемы разницы нет вообще. А появляется она только когда бы ведем речь про сериализацию. Но сериализация сама по себе не привязана к файлам, файл это только способ хранения.

0

Сообщение от DrOffset Файловой системе все равно какие данные хранить.

А она то здесь при чём? Речь о том, что представление скалярных данных с sizeof>1 в оперативе зависит от процессора, а если они ещё и входят в объекты/структуры, то добавляется выравнивание для оптимизации доступа, причём, одному процессору имеет смысл равнять только одиночные, двойные и четверные слова, а другому и на восьмерные

0

Сообщение от taras atavin А она то здесь при чём?

Тогда причем здесь файлы?

Сообщение от taras atavin Речь о том, что представление скалярных данных с sizeof>1 в оперативе зависит от процессора, а если они ещё и входят в объекты/структуры, то добавляется выравнивание для оптимизации доступа, причём, одному процессору имеет смысл равнять только одиночные, двойные и четверные слова, а другому и на восьмерные

Это все понятно, только как это относится к файлам? Сохранение данных в том виде, в котором они находятся в памяти - один из способов бинарной сериализации. К файлам это имеет отношение опосредованное.

0

Сообщение от DrOffset Тогда причем здесь файлы?

Ну мы же не колоду перфокарт обсуждаем?

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

Сообщение от DrOffset Это все понятно, только как это относится к файлам?

Прямо. Это только при ручном вводе местная реализация потока сама разберётся, как расположить байты в шотинте, а при файловом вводе/выводе если ты положишься только на сериализацю/десерриализацию, то макинтош, моторолла, или ваще какая нибудь экотика тебе элементарно сохранит в порядке байт, который интел не переварит, и 257 превратится в 513, чтоб этого не произошло, порядок байт оговаривается в файловом формате, а при несовпадении с процессорным порядком байты меняются местами при каждом чтении/записи.

0

Сообщение от taras atavin Ну мы же не колоду перфокарт обсуждаем?

Я всего лишь хотел указать на некоторое смысловое различие между файлом как таковым (в терминах файловой системы и файлового API ввода-вывода) и форматом, который в этот файл можно поместить. Для этого и были заданы некоторые уточняющие вопросы чтобы понять что понимается тобой под файлом.
Если бы мы рассматривали файл, как он понимается в системах UNIX, то доводы были бы несколько иными.
Не зря alsav22 спрашивал про характер данных, это очень важно для правильной оценки ситуации.

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

Сообщение от taras atavin если ты положишься только на сериализацю/десерриализацию, то макинтош, моторолла, или ваще какая нибудь экотика тебе элементарно сохранит в порядке байт, который интел не переварит

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

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

Вот именно, что в формате.

0

Сообщение от DrOffset Я всего лишь хотел указать на некоторое смысловое различие между файлом как таковым (в терминах файловой системы и файлового API ввода-вывода) и форматом, который в этот файл можно поместить.

В отрыве от формата всякое обсуждение файлов сводится лишь к общим словам опять таки о форматах.

0

Сообщение от taras atavin В отрыве от формата всякое обсуждение файлов сводится лишь к общим словам опять таки о форматах.

Наконец-то ты понял
В отрыве от формата файл можно обсуждать в терминах файловой системы (что и было сделано).

0

Сообщение от DrOffset Вот именно, что в формате.

Ещё раз. С бинарным форматом могут не совпасть особенности процессора, что вынудит выполнять преобразования порядка/выравнивания при каждом чтении/-записи, а с текстовым форматом могут не совпасть только вкусы пользователя и приложения и замены выносятся в отдельную операцию преобразования формата.

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

Сообщение от DrOffset В отрыве от формата файл можно обсуждать в терминах файловой системы (что и было сделано).

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

0