5 ГБ изображений в формате JPEG занимают столько же времени для загрузки и / или импорта, сколько 5 ГБ обычного текста?

Просто интересно, так как сейчас я импортирую все свои фотографии с компакт-диска, который мой папа записал для меня. Мне было любопытно, если 5 ГБ изображений занимали столько же времени, сколько 5 ГБ текста при выполнении такого рода передач. Поскольку могут быть «накладные расходы», связанные с различными форматами файлов, даже если они имеют кумулятивно одинаковый размер ...

редактировать: это на самом деле не CD-ROM, а DVD-R

Ответ «это зависит». Зависит от того, что вы подразумеваете под «скачать».

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

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

Нет никакой разницы в «накладных расходах», связанных с передачей файла, независимо от того, что это за файл.

С 5 ГБ изображений вы, вероятно, будете говорить о нескольких тысячах файлов разумного размера, скажем, 3 МБ + каждый. Если вы загрузили 5 ГБ текстовых файлов, вы обычно ожидаете, что каждый файл будет намного меньше. Таким образом, вы, вероятно, имеете дело с порядком величины или двумя дополнительными файлами (сотнями тысяч или миллионами файлов).

Копирование большого количества маленьких файлов занимает больше времени, чем копирование того же объема данных в больших файлах. Существуют разумные накладные расходы при создании каждого отдельного файла.

Не достаточно, чтобы иметь огромное значение, вероятно, но все же разница.

«Это зависит» в ftp в мелких деталях.

Бинарный режим ftp просто прямая передача и займет 5 ГБ времени.

Если вы переходите с Windows на Linux как передачу текста по протоколу ftp (на удивление, по обычному тексту), ftp фактически меняет окончания строк с / r / n на / n и наоборот. Вероятно, в замене потоковых данных есть небольшие издержки, но с 5 ГБ текста вам будет меньше писать на диск при переходе от win к lin, когда вы будете сбрасывать по одному символу на строку, и больше при переходе с lin на win, когда вы добавляете один символ за строку

Итак, это 5GB на Linux? или винда?

Достаточно педантизма на одну ночь, ложусь спать!

С самими файлами не связано никаких накладных расходов, но некоторые средства хранения / передачи поддерживают автоматическое сжатие, и это может привести к разнице.

При копировании с DVD на несжатый диск разницы нет. При копировании на сжатый диск NTFS текст будет занимать меньше места, чем JPEG.

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

Кроме того, если говорить о накладных расходах, миллион маленьких файлов общим объемом 5 ГБ займет больше [фактического] пространства и обычно больше времени для копирования, чем один файл 5 ГБ, поскольку эти 5 ГБ не включают пространство, необходимое для хранения имен файлов, дат и других метаданных ,

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

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

Прежде чем приступить к использованию веб-сервисов, мы хотели узнать разницу в эффективности между их использованием и использованием более «стандартного» подключения к базе данных (например, OleDb, System.Data.SqlClient, JDBC и т. Д.). Наш гуру установил анализаторы пакетов для отслеживания потоков данных в сети, чтобы увидеть разницу.

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

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

Мы обнаружили, что это интересно, и попробовали это при передаче файлов разных типов, и обнаружили, что, как правило, обычный текст, проходящий по сети, всегда использовал 100% битов, доступных в каждом пакете, где двоичные передачи часто имели неиспользуемые биты. Почему, я не могу вам сказать, но несколько экспериментов подтвердили это.

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

Потому что я не могу удержаться от аналогий, которые могут понять не-айтишники:

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

Традиционная мудрость гласит, что 5 ГБ - это 5 ГБ. Тем не менее, есть некоторые сценарии, где эти два не похожи; это связано с тем, как структурированы данные файлов.

Прежде всего, JPEG сжаты. Чтобы просмотреть изображение, файл сначала должен быть распакован, и для подавляющего большинства таких изображений у вас должен быть весь файл, чтобы сделать это. Существуют прогрессивные JPEG, которые обеспечивают итеративно более четкое изображение при загрузке, но они редко используются в эпоху, когда DSL и другие высокоскоростные соединения очень распространены. Текст, с другой стороны, более или менее разборчив; как только у вас есть байт (или два, или четыре, в зависимости от используемой кодировки UTF), вы можете показать этот символ. Даже самые старые механизмы передачи данных могут загружать текст быстрее, чем вы можете его прочитать. Таким образом, JPEG 5 ГБ займет больше времени для отображения чего-либо, чем текстовый файл 5 ГБ.

Во-вторых, также из-за того, что JPEG сжаты, они плохо работают с браузерами или программами / протоколами передачи файлов, которые сжимают большие объемы данных перед передачей. Вы можете увидеть это, запаковав ZIP-файл; если второй процесс ZIP не будет настроен на большее сжатие (замедление), вы не увидите большой разницы в размерах. Это означает, что при использовании одного из этих инструментов 5 ГБ - это не 5 ГБ; размер JPEG по-прежнему будет около 5 ГБ, но текст можно сжать, возможно, до 1 ГБ или менее. Если бы вы сравнивали 5 ГБ растровых файлов с 5 ГБ простого текста, сравнение было бы намного ближе.

Однако простое перемещение 5 ГБ файлов с одного компьютера на другой с использованием NTP, FTP или HTTP без использования какого-либо сжатия или механизма «doanload booster» в целом займет примерно столько же времени; любая разница будет результатом различий в уровнях сетевого трафика в любую секунду во время каждой передачи.

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

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