Czy pobranie 5 GB obrazów JPEG i pobranie takiego samego czasu zajmuje 5 GB zwykłego tekstu?

Zastanawiam się, ponieważ teraz importuję wszystkie moje zdjęcia z płyty CD, którą mój tata dla mnie nagrał. Byłem ciekaw, czy 5 GB zdjęć zajmuje tyle samo czasu, co 5 GB tekstu podczas wykonywania tego rodzaju transferów. Ponieważ mogą istnieć „koszty ogólne” związane z różnymi formatami plików, nawet jeśli ich łączny rozmiar jest taki sam ...

edycja: tak naprawdę nie jest to płyta CD-ROM, ale płyta DVD-R

Odpowiedź brzmi „to zależy”. Zależy od tego, co rozumiesz przez „pobieranie”.

Jeśli pobierasz ze strony internetowej, niektóre strony automatycznie kompresują pliki „w locie”, a tekst kompresuje się bardzo dobrze, podczas gdy JPEG jest już skompresowany, więc w ogóle nie będzie kompresowany. W takim przypadku będzie duża różnica.

Jeśli używasz tylko polecenia kopiowania do kopiowania plików z jednego komputera na inny, nie będzie różnicy. Jeśli jednak używasz jakiegoś specjalistycznego narzędzia, zależy to od tego, czy narzędzie to używa automatycznej kompresji, czy nie. Jedyną różnicą między JPEG i tekstem jest możliwość kompresji plików.

Nie ma różnicy w „narzutach” związanych z przesyłaniem plików, bez względu na plik.

Przy 5 GB zdjęć prawdopodobnie mówisz o kilku tysiącach plików o rozsądnej wielkości, powiedzmy 3 MB + każdy. Jeśli pobierałeś 5 GB plików tekstowych, zwykle spodziewałbyś się, że każdy plik będzie znacznie mniejszy. Prawdopodobnie zajmowałbyś się rzędem wielkości lub dwoma dodatkowymi plikami (setki tysięcy lub miliony plików).

Kopiowanie wielu małych plików trwa dłużej niż kopiowanie tej samej ilości danych w większych plikach. Tworzenie poszczególnych plików wiąże się z dużym nakładem pracy.

Prawdopodobnie nie wystarczy, aby zrobić ogromną różnicę, ale nadal różnicę.

„To zależy” w ftp jest w drobnych szczegółach.

ftp Tryb binarny to zwykły transfer, który zajmie czas potrzebny na 5 GB.

Jeśli przechodzisz z Windowsa na Linuksa jako transfer tekstu ftp (co zaskakujące, zwykły tekst), ftp faktycznie zmienia zakończenia linii z / r / n na / n i odwrotnie. Prawdopodobnie jest trochę narzutu w zamianie przesyłania strumieniowego, ale przy 5 GB tekstu będziesz musiał mniej pisać na dysk, przechodząc od wygranej do linii, gdy upuszczasz jeden znak w linii, a więcej przechodząc od linii do wygranej, gdy dodajesz jeden znak Za linię.

Czy w systemie Linux jest to 5 GB? lub Windows?

Dosyć pedanterii na jedną noc, idę spać!

Nie ma narzutu związanego z samymi plikami, ale niektóre funkcje przechowywania / przesyłania obsługują automatyczną kompresję, co może wprowadzić różnicę.

Podczas kopiowania z DVD na nieskompresowany napęd nie ma różnicy. Podczas kopiowania na skompresowany dysk NTFS tekst zajmie mniej miejsca niż JPEG.

Podczas pobierania z serwera HTTP korzystającego z kompresji pobieranie tekstu zajmuje mniej czasu. Ale jeśli serwer nie używa kompresji, nie będzie różnicy.

Mówiąc o kosztach ogólnych, milion małych plików o całkowitej wielkości 5 GB zajmie więcej [rzeczywistego] miejsca i zwykle więcej czasu na skopiowanie niż pojedynczy plik 5 GB, ponieważ ten 5 GB nie obejmuje miejsca potrzebnego do przechowywania nazw plików, dat i innych metadanych .

Ma to stanowić dodatek do innych odpowiedzi dotyczących kompresji itp. Jako czynników wpływających na wydajność i czas pobierania.

Jedną z kwestii, o których jeszcze nie wspomniano, jest wydajność pakietów . Wątpię, czy większość ludzi nawet się na to natknęła, więc oto krótkie tło.

Zanim zdecydowaliśmy się na korzystanie z usług internetowych, chcieliśmy poznać różnicę między wydajnością korzystania z nich a użyciem bardziej „standardowego” połączenia z bazą danych (np. OleDb, System.Data.SqlClient, JDBC itp.). Nasz guru umieścił sniffery pakietów w miejscu, aby śledzić strumienie danych w sieci, aby zobaczyć różnicę.

Spodziewaliśmy się, że korzystanie z usług internetowych będzie mniej wydajne z powodu binarnego formatu innych rodzajów połączeń oraz dodatkowego obciążenia znaczników XML używanych do opisywania danych.

Odkryliśmy, że usługi sieciowe były w wielu przypadkach BARDZIEJ wydajne, przynajmniej w naszej sieci. Różnica polegała na tym, że podczas przesyłania danych binarnych niektóre bajty w pakietach były puste, ale podczas wysyłania danych tekstowych pakiety były wykorzystywane bardziej wydajnie.

Okazało się to interesujące i wypróbowaliśmy to podczas przesyłania różnego rodzaju plików i stwierdziliśmy, że z reguły zwykły tekst przechodzący przez sieć zawsze zużywał 100% bitów dostępnych w każdym pakiecie, gdzie transfery binarne często miały nieużywane bity. Dlaczego tak jest, nie mogłem ci powiedzieć, ale niosło to ze sobą kilka eksperymentów.

Kilka komentarzy do tego pytania wydawało się odrzucać to jako oczywiście błędne pytanie, ale tak naprawdę nie jest. Mimo że ilość danych pozostaje taka sama, liczy się również wydajność potoku.

Ponieważ nie mogę się oprzeć tworzeniu analogii, które zrozumiałaby osoba niebędąca informatykiem:

Pojedyncza półka w zamrażarce w sklepie spożywczym ma x miejsca, ale możesz zmieścić więcej galonów lodów na półce, jeśli pojemniki są kwadratowe, niż możesz, jeśli są okrągłe, z powodu zmarnowanej przestrzeni utworzonej przez użycie okrągłego pojemniki Nasze testy, choć początkowo sprzeczne z intuicją, powiedziały nam, co mógł nam powiedzieć każdy sprzedawca w sklepie spożywczym.

Tradycyjna mądrość mówi, że 5 GB to 5 GB. Istnieją jednak scenariusze, w których te dwa nie są do siebie podobne; ma to związek z różnicą w strukturze danych plików.

Po pierwsze, pliki JPEG są kompresowane. Aby wyświetlić obraz, plik musi być najpierw nieskompresowany, a dla przeważającej większości takich obrazów musisz mieć cały plik, aby to zrobić. Istnieją progresywne pliki JPEG, które zapewniają iteracyjnie ostrzejszy obraz podczas wczytywania, ale rzadko są już używane w czasach, w których DSL i inne szybkie połączenia są bardzo powszechne. Z drugiej strony tekst jest mniej lub bardziej strumieniowy; jak tylko masz bajt (lub dwa lub cztery, w zależności od zastosowanego kodowania UTF), możesz pokazać ten znak. Nawet najstarsze mechanizmy przesyłania danych mogą ładować tekst szybciej niż można go odczytać. Tak więc plik JPEG o rozmiarze 5 GB potrzebowałby więcej czasu na wyświetlenie niż plik tekstowy o wielkości 5 GB.

Po drugie, ponieważ pliki JPEG są skompresowane, nie działają one dobrze z przeglądarkami lub programami / protokołami do przesyłania plików, które kompresują duże ilości danych przed transmisją. Możesz to zobaczyć przez skompresowanie pliku ZIP; chyba że drugi proces ZIP został skonfigurowany do bardziej kompaktowego (spowolnienia), nie zobaczysz dużej różnicy w rozmiarze. Oznacza to, że przy korzystaniu z jednego z tych narzędzi 5 GB nie jest 5 GB; JPEG nadal będzie mieć około 5 GB, ale tekst można skompresować, może nawet do 1 GB lub mniej. Gdyby porównać 5 GB plików bitmapowych z 5 GB zwykłego tekstu, porównanie byłoby znacznie bliższe.

Jednak samo przeniesienie 5 GB plików z jednego komputera na drugi przy użyciu NTP, FTP lub HTTP, bez jakiejkolwiek kompresji lub mechanizmu „doanload booster”, zajmie w sumie mniej więcej tyle samo czasu; każda różnica byłaby wynikiem różnych poziomów ruchu sieciowego w każdej sekundzie podczas każdego transferu.

5 GB z napędu optycznego powinno być takie samo - jeśli JPG lub tekst. Przesyłane przez sieć pamiętam czasy modemów, które miały, w zależności od sprzętu, wbudowaną kompresję, tak że już skompresowany plik JPG o pojemności 5 GB nie będzie dalej kompresowany, ale tekst o pojemności 5 GB zwykle ma duży potencjał kompresja.

Dlaczego więc nie jest to używane w przypadku dysków twardych? Może potrzebujesz zbyt dużo logiki na dysku twardym, zbyt wrażliwej na kompresję nagrzewania dysku twardego i zbyt łatwej kompresji danych, jeśli chcesz? Może istnieje dla niektórych dysków?