5 GBのjpegイメージのダウンロードやインポートに、5 GBのプレーンテキストと同じ時間がかかりますか？

ただ不思議なことに、今は父が私のために焼いたCDからすべての写真をインポートしています。これらの種類の転送を行うときに、5 GBの写真が5 GBのテキストと正確に同じ時間を要したかどうかに興味がありました。累積的に同じサイズであっても、さまざまなファイル形式に関連付けられた「オーバーヘッド」がある可能性があるため...

編集：実際にはCD-ROMではなく、DVD-Rです

答えは「依存する」です。「ダウンロード」の意味によって異なります。

Webサイトからダウンロードする場合、一部のサイトは自動的にファイルを「オンザフライ」で圧縮し、テキストは非常によく圧縮されますが、JPEGは既に圧縮されているため、まったく圧縮されません。この場合、大きな違いがあります。

コピーコマンドを使用して1つのコンピューターから別のコンピューターにファイルをコピーする場合は、違いはありません。ただし、何らかの特殊なツールを使用している場合は、そのツールが自動圧縮を使用するかどうかによって異なります。jpegとテキストの唯一の違いは、ファイルを圧縮する可能性です。

ファイルの種類に関係なく、ファイル転送に関連する「オーバーヘッド」に違いはありません。

5GBの写真を使用すると、数千の妥当なサイズのファイル（それぞれ3MB以上）について話している可能性があります。5GBのテキストファイルをダウンロードした場合、通常は各ファイルがはるかに小さくなると予想されます。したがって、おそらく1桁または2つの追加ファイル（数十万または数百万のファイル）を処理することになります。

小さなファイルを大量にコピーすると、同じサイズのデータ​​を大きなファイルにコピーするよりも時間がかかります。個々のファイルの作成には、合理的なオーバーヘッドがあります。

おそらく大きな違いを生むには十分ではありませんが、それでも違いはあります。

ftpの "It Depends"は詳細にあります。

ftpバイナリモードは単なる転送であり、5GBの時間がかかります。

ftpテキスト転送としてWindowsからLinuxに移動する場合（驚くべきことにプレーンテキストの場合）、ftpは実際に行末を/ r / nから/ nに、またはその逆に変更します。ストリーミングの置換にはおそらく多少のオーバーヘッドがありますが、5GBのテキストを使用すると、1行に1文字をドロップするときにwinからlinに移行するディスクへの書き込みが少なくなり、1文字を追加するときにlinからwinに移行する時間が増えます行ごと。

それでは、Linuxで5GBですか？またはWindows？

寝るのに十分な一晩のペダントリー！

ファイル自体に関連するオーバーヘッドはありませんが、一部のストレージ/転送機能は自動圧縮をサポートしているため、違いが生じる可能性があります。

DVDから非圧縮ドライブにコピーする場合、違いはありません。圧縮されたNTFSドライブにコピーする場合、テキストはJPEGよりもスペースを取りません。

圧縮を使用するHTTPサーバーからダウンロードする場合、テキストのダウンロード時間が短くなります。ただし、サーバーが圧縮を使用しない場合、違いはありません。

また、オーバーヘッドについて言えば、合計サイズ5GBの小さなファイル100万個は、単一の5GBファイルよりも多くの[実際の]スペースとコピーに時間がかかります。5GBには、ファイル名、日付、およびその他のメタデータ。

これは、効率やダウンロード時間に影響する要因として、圧縮などに対処する他の回答に追加することを意味します。

まだ言及されていなかった1つのポイントは、パケット効率です。ほとんどの人がこれに出くわしたことすらないと思うので、ここで簡単な背景を説明します。

Webサービスを使用する前に、Webサービスの使用と、より「標準的な」データベース接続（OleDb、System.Data.SqlClient、JDBCなど）の使用の効率の違いを知りたいと思いました。違いを確認するために、ネットワーク全体のデータストリームを追跡するために、グルにパケットスニファを配置してもらいました。

他の種類の接続のバイナリ形式と、データの記述に使用されるXMLタグのオーバーヘッドが追加されるため、Webサービスの使用は効率が低下すると考えられました。

私たちが見つけたのは、少なくとも私たちのネットワーク上で、Webサービスが、多くの場合、より効率的であるということです。違いは、バイナリデータを転送しているとき、パケット内のバイトの一部が空でしたが、テキストデータを送信するとき、パケットがより効率的に使用されたことです。

これは興味深いものであり、さまざまな種類のファイルを転送しながら試してみましたが、原則として、ネットワークを通過するプレーンテキストは常に、各パケットで使用可能なビットの100％を使用することがわかりました。なぜそうなのかは言えませんが、いくつかの実験がこれを裏付けました。

質問に対するいくつかのコメントは、これを明らかに欠陥のある質問として却下するように見えましたが、実際にはそうではありません。データの量は同じままですが、パイプの効率も重要です。

非IT者が理解するであろう類似性を作ることに抵抗することはできないからです：

食料品店の冷凍庫にある1つの棚にはxのスペースがありますが、丸い容器を使用するとスペースが無駄になるため、丸い容器よりも正方形の容器の方がアイスクリームのガロンを棚に収めることができますコンテナ。私たちのテストは、最初は直感に反していましたが、食料品店のストッカーが私たちに言ったことを教えてくれました。

伝統的な知恵では、5GBは5GBと言われています。ただし、これら2つが似ていないシナリオがいくつかあります。ファイルのデータの構造の違いに関係しています。

まず、JPEGは圧縮されます。画像を表示するには、最初にファイルを圧縮解除する必要があります。そのような画像の圧倒的多数では、これを行うにはファイル全体が必要です。読み込み時に反復的に鮮明な画像を提供するプログレッシブJPEGがありますが、DSLやその他の高速接続が非常に一般的である時代には使用されることはほとんどありません。一方、テキストは多かれ少なかれストリーミング可能です。バイト（または使用されているUTFエンコーディングに応じて2つまたは4つ）があればすぐに、その文字を表示できます。最も古いデータ転送メカニズムでさえ、テキストを読むよりも速く読み込むことができます。そのため、5GBのJPEGでは、5GBのテキストファイルよりも何かを表示するのに時間がかかります。

第二に、JPEGは圧縮されているため、送信前に大量のデータを圧縮するブラウザーまたはファイル転送プログラム/プロトコルではうまく機能しません。これを確認するには、ZIPファイルをZIP圧縮します。2番目のZIPプロセスがさらに圧縮（低速化）するように構成されていない限り、サイズに大きな違いは見られません。つまり、これらのツールのいずれかを使用する場合、5GBは5GBではありません。JPEGはまだ約5GBになりますが、テキストは1GB以下まで圧縮できます。5GBのビットマップファイルと5GBのプレーンテキストを比較する場合、比較ははるかに近くなります。

ただし、NTPまたはFTPまたはHTTPを使用して、圧縮または「doanloadブースター」メカニズムを使用せずに、あるコンピューターから別のコンピューターに5GBのファイルを移動するだけでは、全体でほぼ同じ時間がかかります。違いは、各転送中の任意の1秒でのネットワークトラフィックレベルの違いの結果です。

光学ドライブの5 GBは、JPGまたはテキストの場合、同じである必要があります。ネット経由で転送すると、ハードウェアに応じて組み込みの圧縮が行われたモデムの時間を覚えているので、すでに圧縮された5 GB JPGはさらに圧縮されませんが、5 GBのテキストは通常​​、圧縮。

では、なぜこれがハードドライブに使用されないのですか？必要に応じて、ハードドライブに多くのロジックが必要になり、ハードドライブを過度に加熱する圧縮に脆弱になりすぎ、必要に応じてデータを明示的に圧縮するのが簡単になりますか？ドライブによっては存在するのでしょうか？