Чи потрібно 5 ГБ зображень jpeg завантажити та / або імпортувати 5 Гб простого тексту?

Цікаво, адже зараз я імпортую всі свої фотографії з компакт-диска, який мій батько записав для мене. Мені було цікаво, якщо 5 Гб фотографій займало стільки ж часу, скільки 5 ГБ тексту, коли робили такі передачі. Оскільки з різними форматами файлів можуть бути "накладні витрати", навіть якщо вони кумулятивно однакового розміру ...

редагувати: це насправді не CD-ROM, а DVD-R

Відповідь "це залежить". Залежить від того, що ви розумієте під "завантаженням".

Якщо ви завантажуєте з веб-сайту, то деякі сайти автоматично стискають файли "на льоту", і текст стискається дуже добре, тоді як JPEG вже стислий, тому він не стиснеться зовсім. У цьому випадку буде велика різниця.

Якщо ви просто використовуєте команду copy, щоб копіювати файли з одного комп'ютера на інший, то різниці не буде. Однак якщо ви використовуєте якийсь спеціалізований інструмент, то знову ж таки, це залежить від того, використовує цей інструмент автоматичне стиснення чи ні. Єдина відмінність jpeg від тексту - це можливість стиснення файлів.

Немає різниці в "накладних витратах", пов'язаних з передачею файлів, незалежно від того, який файл.

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

Копіювання багатьох невеликих файлів займає більше часу, ніж копіювання однакової кількості даних у більші файли. У створенні кожного окремого файлу є розумні витрати.

Мало того, щоб, мабуть, змінити масштабну ситуацію, але все-таки різниця.

"Це залежить" у ftp детально описано.

ftp Бінарний режим - це просто пряма передача, і це займе час, необхідний для 5 Гб.

Якщо ви переходите з Windows до Linux у вигляді передачі тексту у форматі ftp (на диво, простого тексту), ftp фактично змінює закінчення рядка з / r / n на / n і навпаки. Напевно, в режимі поточної заміни є невеликі накладні витрати, але з 5 Гб тексту вам доведеться менше писати на диск, переходячи від виграшу до ліна, коли ви скидаєте один символ на рядок, і більше переходите з ліні на перемогу, додаючи один символ за рядок.

Отже, це 5 Гб на Linux? чи Windows?

Достатньо педантичності на одну ніч, лягаючи спати!

Немає накладних витрат, пов'язаних із самими файлами, але деякі засоби зберігання / передачі підтримують автоматичне стиснення, і це може ввести різницю.

При копіюванні з 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 без будь-якого використовуваного механізму стиснення або "підсилення завантаження" займе приблизно однаковий час; будь-яка різниця буде результатом різного рівня мережевого трафіку в будь-яку секунду під час кожної передачі.

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

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