Apakah 5 GB gambar jpeg membutuhkan waktu yang sama untuk mengunduh dan / atau mengimpor 5GB teks biasa?


39

Hanya ingin tahu, karena sekarang saya mengimpor semua gambar saya dari CD yang dibakar ayah saya untuk saya. Saya ingin tahu apakah 5 GB gambar mengambil jumlah waktu yang sama persis dengan 5 GB teks saat melakukan transfer semacam ini. Karena mungkin ada 'overhead' yang terkait dengan format file yang berbeda walaupun ukurannya secara kumulatif sama ...

sunting: ini sebenarnya bukan CD-rom tetapi DVD-R


11
5 pertunjukan adalah 5 pertunjukan kecuali jika tidak.
Xavierjazz

2
Tidak bisa berdebat dengan itu ...
Thomas Padron-McCarthy

35
Yang lebih berat: satu ton batu bata, atau satu ton bulu?
Graham Borland

1
Lihat jawaban saya (dan yang bagus lainnya yang menyoroti berbagai faktor) sebelum menolak ini sebagai pertanyaan yang jelas-jelas buruk. 5GB mungkin 5GB, tetapi efisiensi pipa yang dilalui data membuat perbedaan.
David Stratton

1
@ Graham: Mana yang lebih berat, satu pon bulu atau satu pon emas? (jawaban)
BlueRaja - Danny Pflughoeft

Jawaban:


75

Jawabannya adalah, tergantung". Tergantung apa yang Anda maksud dengan "unduh".

Jika Anda mengunduh dari situs web, daripada beberapa situs secara otomatis kompres file "dengan cepat", dan teks dikompres dengan sangat baik, sementara JPEG sudah dikompresi, jadi tidak akan kompres sama sekali. Dalam hal ini, akan ada perbedaan besar.

Jika Anda hanya menggunakan perintah salin untuk menyalin file dari satu komputer ke komputer lain, maka tidak akan ada perbedaan. Namun, jika Anda menggunakan beberapa jenis alat khusus, sekali lagi, itu tergantung apakah alat itu menggunakan kompresi otomatis atau tidak. Satu-satunya perbedaan antara jpeg dan teks adalah kemungkinan untuk mengompres file.

Tidak ada perbedaan dalam 'overhead' yang terkait dengan transfer file, tidak peduli apa file tersebut.


29
Dalam hal salinan, jika ukuran keseluruhannya sama maka jumlah file lebih cenderung berdampak karena ada overhead dalam mentransfer metadata file / folder.
Chris Nava

2
@ chris-nava: Ya, ini sangat benar. Saya hanya mempertimbangkan file dengan ukuran yang sama, tetapi Anda benar untuk menunjukkan nuansa ini.
haimg

2
@DarkTemplar: ini termasuk metadata. Hampir selalu. Biasanya jumlah metadata yang disimpan "di luar" file sangat terbatas: nama file, izin dan beberapa waktu akses. Banyak sistem file memiliki opsi untuk menyimpan meta-data yang sewenang-wenang (bahkan besar) "di luar" file, tetapi itu jarang digunakan.
Joachim Sauer

4
Mekanisme transfer juga bisa menjadi sumber keterlambatan. Misalnya SMB (Windows File Sharing) BAD saat mentransfer sejumlah besar file kecil sementara NFS atau FTP jauh lebih cepat untuk set file yang sama.
Chris Nava

4
Saya terkejut tidak ada yang menyebutkan kemungkinan anti-virus menambahkan beberapa overhead yang signifikan. Banyak aplikasi anti-virus memindai file JPEG untuk mencari virus, dan mengabaikan dokumen teks. Ini pasti bisa berkontribusi untuk itu tergantung faktor.
Scott Rippey

17

Dengan 5GB gambar Anda cenderung berbicara tentang beberapa ribu file berukuran cukup, katakanlah masing-masing 3MB +. Jika Anda mengunduh file teks 5GB, biasanya Anda berharap setiap file jauh lebih kecil. Jadi, Anda kemungkinan akan berurusan dengan urutan besarnya atau dua file tambahan (ratusan ribu atau jutaan file).

Menyalin banyak file kecil membutuhkan waktu lebih lama daripada menyalin jumlah data yang sama dalam file yang lebih besar. Ada overhead yang wajar dalam membuat setiap file individual.

Mungkin tidak cukup untuk membuat perbedaan besar, tetapi masih membuat perbedaan.


3
Saya pikir ini bisa membuat perbedaan besar. Menyalin seratus file teks 30K pasti dapat memakan waktu lebih lama daripada menyalin satu file 3MB, tergantung di mana Anda menyalin ke dan dari.
Steven Noto

+1 Untuk mengatasi masalah sebenarnya di sini. Sejauh ini jawaban terbaik.
artistoex

12

"Itu Tergantung" di ftp ada di detail halus.

ftp Binary mode hanya transfer langsung dan akan memakan waktu 5GB.

Jika Anda pergi dari Windows ke Linux sebagai transfer teks ftp (untuk mengejutkan, teks biasa), ftp sebenarnya mengubah akhir baris dari / r / n ke / n dan sebaliknya. Mungkin ada sedikit overhead dalam penggantian streaming, tetapi dengan 5GB teks, Anda akan memiliki lebih sedikit untuk menulis ke disk dari win ke lin saat Anda menjatuhkan satu karakter per baris, dan lebih banyak dari lin untuk menang saat Anda menambahkan satu karakter per baris.

Jadi, apakah 5GB di Linux? atau Windows?

Pedantri yang cukup untuk satu malam, tidur!


Bagaimana kami bisa sampai ke FTP? OP tampaknya menyalin dari drive DVD ke drive lokal?
andynormancx

Dari judulnya. 'Sungguh larut malam dan saya menjawab pertanyaan, bukan paragraf di bawahnya. Begitu juga poster dengan suara tertinggi di paragraf awal. Sekarang untuk menyalin dari satu media ke media lain ...
Fiasco Labs

3

Tidak ada overhead yang terkait dengan file itu sendiri, tetapi beberapa fasilitas penyimpanan / transfer mendukung kompresi otomatis, dan itu mungkin menimbulkan perbedaan.

Saat menyalin dari DVD ke drive yang tidak dikompresi, tidak ada perbedaan. Saat menyalin ke drive NTFS terkompresi, teks akan mengambil lebih sedikit ruang daripada JPEG.

Saat mengunduh dari server HTTP yang menggunakan kompresi, teks akan membutuhkan waktu lebih sedikit untuk diunduh. Tetapi jika server tidak menggunakan kompresi, tidak akan ada perbedaan.

Juga, berbicara tentang overhead, satu juta file kecil ukuran total 5GB akan mengambil lebih banyak ruang [aktual] dan biasanya lebih banyak waktu untuk menyalin daripada file 5GB tunggal, karena 5GB itu tidak termasuk ruang yang diperlukan untuk menyimpan nama file, tanggal dan metadata lainnya .


3

Ini dimaksudkan sebagai tambahan untuk jawaban lain yang membahas kompresi, dll sebagai faktor yang memengaruhi efisiensi dan waktu pengunduhan.

Satu hal yang belum disebutkan adalah efisiensi paket . Saya ragu sebagian besar orang bahkan menemukan ini, jadi inilah sedikit latar belakang.

Sebelum mencoba menggunakan layanan web, kami ingin mengetahui perbedaan efisiensi antara menggunakannya dan menggunakan koneksi database yang lebih "standar" (seperti OleDb, System.Data.SqlClient, JDBC, dll). Kami menyuruh guru kami menempatkan sniffer paket untuk melacak aliran data di seluruh jaringan untuk melihat perbedaannya.

Kami berharap bahwa menggunakan layanan web akan kurang efisien karena format biner dari jenis koneksi lainnya, dan tambahan biaya tambahan dari tag XML yang digunakan untuk menggambarkan data.

Apa yang kami temukan adalah bahwa layanan web, dalam banyak kasus LEBIH efisien, setidaknya di jaringan kami. Perbedaannya adalah bahwa ketika mentransfer data biner, beberapa byte dalam paket kosong, tetapi ketika mengirim data teks, paket tersebut digunakan lebih efisien.

Kami menemukan ini menarik, dan mencobanya sambil mentransfer berbagai jenis file, dan menemukan bahwa sebagai aturan, teks biasa yang melewati jaringan selalu menggunakan 100% dari bit yang tersedia di setiap paket, di mana transfer biner sering memiliki bit yang tidak digunakan. Mengapa ini, saya tidak bisa mengatakannya kepada Anda, tetapi beberapa percobaan membuktikan hal ini.

Beberapa komentar pada pertanyaan itu tampaknya menganggap ini sebagai pertanyaan yang jelas cacat, tetapi sebenarnya tidak. Meskipun jumlah data tetap sama, efisiensi pipa, juga penting.

Karena saya tidak bisa menolak membuat analogi yang orang non-IT akan mengerti:

Satu rak dalam freezer di toko grosir memiliki jumlah ruang x, namun Anda dapat memuat lebih banyak galon es krim di rak jika wadahnya persegi daripada yang Anda bisa jika berbentuk bundar, karena ruang terbuang yang dibuat dengan menggunakan putaran wadah. Pengujian kami, meskipun awalnya kontra-intuitif, memberi tahu kami apa yang bisa dikatakan oleh petugas toko bahan makanan.


2
Apa yang terlibat dalam database? RDBMS yang berbeda lebih atau kurang "efisien jaringan" daripada yang lain. Anda diukur dari koneksi atau hanya data dataset? Saya sangat ingin tahu.
Fabricio Araujo

1

Kearifan tradisional mengatakan bahwa 5GB adalah 5GB. Namun, ada beberapa skenario di mana keduanya tidak sama; itu ada hubungannya dengan perbedaan dalam bagaimana data file terstruktur.

Pertama, JPEG dikompresi. Untuk melihat gambar, file pertama-tama harus tidak terkompresi, dan untuk sebagian besar gambar seperti itu, Anda harus memiliki seluruh file untuk melakukan ini. Ada JPEG progresif yang memberikan gambar iteratif lebih tajam saat dimuat, tetapi mereka jarang digunakan lagi di zaman di mana DSL dan koneksi berkecepatan tinggi lainnya sangat umum. Teks, di sisi lain, lebih atau kurang streamable; segera setelah Anda memiliki byte (atau dua atau empat, tergantung pada pengkodean UTF yang digunakan), Anda dapat menunjukkan karakter itu. Bahkan mekanisme transfer data tertua dapat memuat teks lebih cepat dari yang Anda bisa baca. Jadi, JPEG 5GB akan membutuhkan waktu lebih lama untuk dapat menampilkan sesuatu daripada file teks 5GB.

Kedua, juga karena JPEG dikompresi, mereka tidak berfungsi dengan baik dengan browser atau program / protokol transfer file yang memampatkan sejumlah besar data sebelum transmisi. Anda dapat melihat ini dengan ZIP file ZIP; kecuali proses ZIP kedua dikonfigurasi untuk melakukan lebih banyak pemadatan (memperlambatnya), Anda tidak akan melihat banyak perbedaan ukuran. Itu berarti bahwa ketika menggunakan salah satu alat ini, 5GB bukan 5GB; JPEG masih akan sekitar 5GB, tetapi teks dapat dikompresi, mungkin hingga 1GB atau kurang. Jika Anda membandingkan 5GB file bitmap dengan 5GB teks biasa, perbandingannya akan jauh lebih dekat.

Namun, hanya memindahkan 5GB file dari satu komputer ke komputer lain menggunakan NTP, FTP atau HTTP, tanpa mekanisme kompresi atau "doanload booster" yang digunakan, akan memakan waktu yang hampir bersamaan secara keseluruhan; perbedaan apa pun akan terjadi karena perbedaan tingkat lalu lintas jaringan pada setiap detik tertentu selama setiap transfer.


Saya belum pernah mendengar tentang JPG interleaved. Apakah Anda menggabungkan JPG progresif dengan GIF / PNG yang disisipkan?
lembut

Varian "Progressive JPEG" adalah format interlaced seperti interlaced GIF / PNG. Istilah "progresif" untuk JPEG membingungkan IMO, karena istilah terkenal seperti "pemindaian progresif", "720p (rogressive)" dan "1080p". Istilah-istilah tersebut semuanya menunjukkan bahwa seluruh frame digambar dalam resolusi penuh dalam satu lintasan alih-alih dalam dua lintasan interlaced, kebalikan dari perilaku tampilan JPEG "progresif".
KeithS

1
Tapi itu bukan cara kerja JPEG progresif. Ini bukan format interlaced / interleaved seperti GIF atau PNG (atau video DVD, dalam hal ini), ini merupakan perbaikan berulang blok DCT. JPEG progresif sedang berlangsung memiliki cakupan piksel penuh - hanya pada bitrate lebih rendah. JPEG juga tidak berurusan dengan hal-hal dalam scanlines seperti GIF atau PNG, itu berurusan dengan mereka sebagai kumpulan kelompok persegi piksel.
fluffy

Tomat, tomahto. Gambar awalnya ditampilkan menggunakan subset dari data gambar penuh yang datang lebih awal, kemudian disempurnakan dengan sisanya. Itulah poin saya. Baik itu garis atau blok, ini merupakan gaya pemuatan multi-pass yang bertentangan dengan one-pass.
KeithS

Ini bukan hanya perbedaan terminologi kecil seperti yang Anda maksudkan, tetapi ini berubah menjadi argumen dinding bata tanpa alasan yang bagus. Saya hanya mencoba menyarankan suntingan kecil agar Anda menjawab pertanyaan Anda, bukan mencoba masuk ke dalam pertandingan kencing.
lembut

0

5 GB dari drive optik harus sama - jika JPG atau teks. Ditransfer melalui internet, saya ingat waktu modem, yang memiliki, tergantung pada perangkat keras, kompresi bawaan, sehingga JPG 5 GB yang sudah dikompresi tidak akan dikompresi lebih lanjut, tetapi teks 5 GB biasanya memiliki banyak potensi untuk kompresi.

Jadi mengapa ini tidak digunakan untuk harddisk? Mungkin Anda akan membutuhkan terlalu banyak logika pada harddisk, terlalu rentan kompresi memanaskan harddisk terlalu banyak, dan terlalu mudah untuk mengompres data secara eksplisit, jika diinginkan? Mungkin ada untuk beberapa drive?

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.