@nexen

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

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

0

@zss

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

0

alsav22

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

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

1

@nexen

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

0

@DrOffset

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

1

alsav22

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

0

Байт

Чушь!

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

2

@nexen

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

0

@taras atavin

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

0

alsav22

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

0

@DrOffset

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

0

@taras atavin

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

Добавлено через 53 секунды
файл есть наименьшая именованная часть диска.

0

@DrOffset

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

0

@taras atavin

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

0

@DrOffset

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

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

0

@taras atavin

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

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

0

@DrOffset

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

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

0

@taras atavin

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

0

@DrOffset

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

0

@taras atavin

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

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

0