5GB의 JPEG 이미지는 5GB의 일반 텍스트로 다운로드 및 / 또는 가져 오는 데 동일한 시간이 소요됩니까?


39

궁금해서, 지금부터 나는 아빠가 나를 위해 구운 CD에서 모든 사진을 가져오고 있습니다. 이러한 종류의 전송을 수행 할 때 5GB의 사진이 5GB의 텍스트와 동일한 정확한 시간이 소요되면 궁금합니다. cumulatively 동일한 크기의 경우에도 서로 다른 파일 형식과 관련된 '오버 헤드'가있을 수 있기 때문에 ...

편집 : 실제로는 CD-ROM이 아니라 DVD-R입니다.


11
5 기가는 그렇지 않다면 5 기가입니다.
Xavierjazz

2
그것과 논쟁 할 수 없다 ...
Thomas Padron-McCarthy

35
어떤 것이 더 무겁습니까? 1 톤의 벽돌이나 1 톤의 깃털?
Graham Borland

1
명백하게 나쁜 질문으로 이것을 기각하기 전에 내 대답 (그리고 다른 좋은 요인들)을보십시오. 5GB는 5GB가 될 수 있지만 데이터가 이동하는 파이프의 효율성은 차이를 만듭니다.
David Stratton

1
@ 그래함 : 어느 것이 더 무거 우며, 1 파운드의 깃털이나 1 파운드의 금이 있습니까? (대답)
BlueRaja - Danny Pflughoeft

답변:


75

대답은 "의존합니다"입니다. "다운로드"의 의미에 달려 있습니다.

웹 사이트에서 다운로드하는 경우 일부 사이트가 자동으로 파일을 압축하고 텍스트가 매우 잘 압축되지만 JPEG는 이미 압축되어 있으므로 전혀 압축되지 않습니다. 이 경우 큰 차이가 있습니다.

복사 명령을 사용하여 한 컴퓨터에서 다른 컴퓨터로 파일을 복사하는 경우에는 아무런 차이가 없습니다. 그러나 어떤 종류의 특수 도구를 사용하는 경우 도구가 자동 압축을 사용하는지 여부에 따라 다릅니다. jpeg와 텍스트의 유일한 차이점은 파일을 압축 할 수 있다는 것입니다.

파일이 무엇이든 관계없이 파일 전송과 관련된 '오버 헤드'에는 차이가 없습니다.


29
복사본의 경우 전체 크기가 동일하면 번호 의 파일은 파일 / 폴더 메타 데이터를 전송하는 데 오버 헤드가 있으므로 영향을 줄 가능성이 큽니다.
Chris Nava

2
@ chris-nava : 예, 이것은 사실입니다. 필자는 같은 크기의 파일 만 고려했지만이 뉘앙스를 지적하는 것은 맞습니다.
haimg

2
@DarkTemplar : 메타 데이터를 포함합니다. 거의 언제나. 일반적으로 파일 외부에 저장된 메타 데이터의 양은 파일 이름, 권한 및 일부 액세스 시간과 같이 매우 제한적입니다. 많은 파일 시스템에는 선택권 임의의 (심지어 커다란) 메타 데이터를 "외부"파일에 저장하는 것은 거의 불가능합니다.
Joachim Sauer

4
전송 메커니즘은 또한 지연의 원인 일 수 있습니다. 예를 들어, SMB (Windows File Sharing)는 많은 수의 작은 파일을 전송하는 데 불리한 반면 NFS 또는 FTP는 동일한 파일 세트에 대해 훨씬 빠릅니다.
Chris Nava

4
아무도 상당한 오버 헤드로 안티 바이러스를 추가 할 가능성에 대해 아무도 언급하지 않은 것에 놀랐습니다. 많은 안티 바이러스 응용 프로그램은 JPEG 파일에서 바이러스를 검사하고 텍스트 문서는 무시합니다. 이것은 분명히 그것은 달려있다. 인자.
Scott Rippey

17

5GB의 사진으로 합리적인 크기의 파일 몇 천 개, 즉 각각 3MB 이상을 말하는 것 같습니다. 5GB의 텍스트 파일을 다운로드 한 경우 일반적으로 각 파일의 크기가 훨씬 작을 것으로 예상됩니다. 그래서 당신은 아마도 수십억 개의 파일이나 수십만 또는 수백만 개의 파일을 처리 할 것입니다.

작은 파일을 많이 복사하는 것은 더 큰 파일에서 동일한 양의 데이터를 복사하는 것보다 오래 걸립니다. 각 개별 파일을 만드는 데는 상당한 오버 헤드가 있습니다.

아마도 엄청난 차이를 만들 정도로 충분하지는 않지만 여전히 차이가 있습니다.


3
나는 이것이 큰 차이를 만들 수 있다고 생각합니다. 30K 개의 텍스트 파일을 복사하는 것은 어디에서 복사하는지에 따라 3MB 파일 하나를 복사하는 것보다 오래 걸릴 수 있습니다.
Steven Noto

+1 실제 문제를 해결하려면 여기를 클릭하십시오. 멀리 최고의 답변.
artistoex

12

ftp에있는 "It Depends"는 상세한 내용입니다.

ftp 바이너리 모드는 곧바로 전송되며 5GB에 걸리는 시간이 소요됩니다.

ftp는 Windows에서 Linux로 ftp 텍스트 전송 (놀랍게도 일반 텍스트)을한다면, 실제로 / r / n에서 / n으로 그리고 그 반대로 행 끝을 변경합니다. 스트리밍 대체에는 약간의 오버 헤드가있을 수 있지만 5GB의 텍스트를 사용하면 한 줄에 한 글자를 떨어 뜨릴 때 win에서 lin로가는 디스크에 쓰기가 적어지고 한 문자를 추가 할 때 lin에서 이기기 위해 더 많은 노력을 기울일 것입니다 한 줄에

그래서, 리눅스에서 5GB입니까? 또는 Windows?

잠자리에 들기에 충분한 밤간의 대농장!


FTP에 어떻게 접근 했습니까? OP가 DVD 드라이브에서 로컬 드라이브로 복사 중입니까?
andynormancx

제목에서. 늦은 밤에 Twas와 내가 그 질문에 답했다, 그것 아래의 단락이 아니라. 그의 초기 단락에서 가장 높은 표를 얻은 포스터도 마찬가지입니다. 이제 한 미디어에서 다른 미디어로 복사하는 중 ...
Fiasco Labs

3

파일 자체와 관련된 오버 헤드는 없지만 일부 저장 / 전송 기능은 자동 압축을 지원하므로 차이가 발생할 수 있습니다.

DVD에서 비 압축 드라이브로 복사 할 때 차이점은 없습니다. 압축 NTFS 드라이브에 복사 할 때 텍스트는 JPEG보다 공간이 적습니다.

압축을 사용하는 HTTP 서버에서 다운로드 할 때 텍스트를 다운로드하는 데 시간이 덜 걸립니다. 그러나 서버가 압축을 사용하지 않으면 차이가 없습니다.

또한 오버 헤드에 대한 이야기, 5GB의 작은 크기의 총 5GB 크기는 파일 이름, 날짜 및 기타 메타 데이터를 저장하는 데 필요한 공간을 포함하지 않으므로 [실제] 공간과 보통 복사하는 데 더 많은 시간이 소요됩니다. .


3

이것은 효율성과 다운로드 시간에 영향을 미치는 요소 들로서 압축 등을 다루는 다른 해답들에 대한 추가 사항입니다.

아직 언급되지 않은 한 가지 점은 패킷 능률. 나는 대부분의 사람들이 이것을 보았을 지 의심 스럽다. 그래서 여기에 간단한 배경 지식이있다.

웹 서비스를 사용하기에 앞서, 웹 서비스를 사용하고보다 "표준적인"데이터베이스 연결 (예 : OleDb, System.Data.SqlClient, JDBC 등)을 사용하는 것의 효율성 차이를 알고 싶었습니다. 차이점을 확인하기 위해 네트워크를 통해 데이터 스트림을 추적하기 위해 우리의 전문가에게 패킷 스니퍼를 설치하도록했습니다.

우리는 웹 서비스를 사용하는 것이 다른 유형의 연결의 바이너리 형식과 데이터를 설명하는 데 사용 된 XML 태그의 추가 된 오버 헤드 때문에 효율성이 떨어질 것으로 예상했습니다.

우리가 발견 한 것은 적어도 웹 서비스가 웹상에서 더 효율적이었습니다. 차이점은 바이너리 데이터를 전송할 때 패킷 내의 일부 바이트가 비어 있었지만 텍스트 데이터를 보낼 때 패킷이 더 효율적으로 사용된다는 점입니다.

우리는이 흥미로운 것을 발견하고 다른 종류의 파일을 전송하는 동안 시도해 보았습니다. 그리고 일반적으로 네트워크를 통해 전달되는 일반 텍스트는 이진 전송에 종종 사용되지 않는 비트가있는 각 패킷에서 사용 가능한 비트의 100 %를 사용했습니다. 왜 그런지, 나는 당신에게 말할 수는 없지만, 몇 가지 실험이 이것을 보였다.

이 질문에 대한 여러 의견은 분명히 결함있는 질문으로이를 무시한 것처럼 보였지만 실제로는 그렇지 않습니다. 비록 데이터의 양이 동일하더라도 파이프의 효율성은 중요합니다.

비 IT 직원이 이해할 수있는 유추에 저항 할 수 없기 때문에 :

식료품 가게의 냉동고에있는 하나의 선반에는 여유 공간이 있지만 라운드를 사용하면 낭비되는 공간 때문에 컨테이너가 사각형보다 큰 경우 선반에 더 많은 갤런의 아이스크림을 담을 수 있습니다 컨테이너. 우리의 테스트는 처음에는 반 직관적 이었지만 어떤 식료품 점 스토커가 우리에게 말했을 수 있는지를 말해주었습니다.


2
관련된 데이터베이스는 무엇입니까? 다른 RDBMS는 다른 것보다 "네트워크 효율"이 높습니다. 연결 설정 또는 데이터 세트 데이터 만 측정 했습니까? 나는 정말로 호기심이 많다.
Fabricio Araujo

1

전통적인 지혜에 따르면 5GB는 5GB입니다. 그러나이 두 시나리오가 유사하지 않은 몇 가지 시나리오가 있습니다. 파일의 데이터 구조가 어떻게 다른지와 관련이 있습니다.

먼저 JPEG가 압축됩니다. 이미지를 보려면 파일을 먼저 압축 해제해야하며 압도적 인 대부분의 이미지의 경우이 작업을 수행하려면 전체 파일을 가져야합니다. 로드 될 때 반복적으로 선명한 사진을 제공하는 점진적 JPEG가 있지만 DSL 및 기타 고속 연결이 매우 흔한 시대에는 거의 사용되지 않습니다. 반면에 텍스트는 다소 스트리밍 가능합니다. 바이트 (또는 사용 된 UTF 인코딩에 따라 두 개 또는 네 개)가 있으면 바로 그 문자를 표시 할 수 있습니다. 가장 오래된 데이터 전송 메커니즘조차도 읽을 수있는 속도보다 빠르게 텍스트를로드 할 수 있습니다. 따라서 5GB JPEG는 5GB 텍스트 파일보다 더 오래 걸릴 수 있습니다.

둘째, 또한 JPEG가 압축되기 때문에 전송 전에 많은 양의 데이터를 압축하는 브라우저 나 파일 전송 프로그램 / 프로토콜에서는 제대로 작동하지 않습니다. ZIP 파일을 ZIPping하여 볼 수 있습니다. 두 번째 ZIP 프로세스가 더 컴팩트 화 (속도 저하)되도록 구성되어 있지 않으면 크기가 크게 달라지지 않습니다. 즉,이 도구 중 하나를 사용할 때 5GB는 5GB가 아닙니다. JPEG는 여전히 약 5GB가 될 것이지만 텍스트는 1GB 이하로 압축 될 수 있습니다. 5GB의 비트 맵 파일과 5GB의 일반 텍스트를 비교하면 비교가 훨씬 더 가까워집니다.

그러나 압축이나 "doanload booster"메커니즘을 사용하지 않고 NTP, FTP 또는 HTTP를 사용하여 한 컴퓨터에서 다른 컴퓨터로 5GB의 파일을 이동하는 작업은 전체적으로 거의 같은 시간이 걸립니다. 차이는 각 전송 중에 주어진 초마다 서로 다른 네트워크 트래픽 수준의 결과 일 수 있습니다.


인터리브 JPG에 대해 들어 본 적이 없습니다. 프로그레시브 JPG와 인터리브 GIF / PNG를 섞어서 사용하고 있습니까?
fluffy

"프로그레시브 JPEG"변형은 인터레이스 된 GIF / PNG와 매우 유사한 인터레이스 형식입니다. JPEG의 "프로그레시브"라는 용어는 "프로그레시브 스캔", "720p (로 직)"및 "1080p"와 같이 잘 알려진 용어로 인해 IMO를 혼란스럽게합니다. 이 용어들은 모두 전체 프레임이 "프로그레시브"JPEG 표시 동작과 정반대 인 두 개의 인터레이스 패스가 아니라 한 패스로 전체 해상도로 그려지는 것을 나타냅니다.
KeithS

1
그러나 이것이 진보 JPEG가 작동하는 방식이 아닙니다. GIF 나 PNG (또는 DVD 비디오)와 같이 인터레이스 / 인터리빙 된 형식이 아니라 DCT 블록을 반복적으로 세분화 한 것입니다. 진행중인 프로그레시브 JPEG는 전체 픽셀 범위를 포함합니다. 단지 더 낮은 비트 전송률에 불과합니다. JPEG는 GIF 또는 PNG와 같은 스캔 라인의 항목을 처리하지 않으며 픽셀의 정사각형 그룹 모음으로 처리합니다.
fluffy

Tomato, tomahto. 이미지는 원래 전체 이미지 데이터의 하위 집합을 사용하여 표시됩니다. 전체 이미지 데이터는 초기에 들어온 다음 나머지 부분으로 세련됩니다. 그것이 내 요점이었습니다. 선이든 블록이든, 원 패스와는 달리 다중 패스 로딩 스타일입니다.
KeithS

그것은 당신이 암시하는 바와 같이 사소한 용어 차이 만은 아니지만, 이것은 정당한 이유없이 벽돌 벽 논쟁으로 바뀌고 있습니다. 나는 당신이 당신의 대답을하기 위해 사소한 편집을 제안하려고 시도했을 뿐이 었으며, 오줌 싸움에 빠지려고하지 않았습니다.
fluffy

0

광학 드라이브의 5GB는 JPG 또는 텍스트 인 경우 동일해야합니다. 인터넷을 통해 전송 된 모뎀의 시간은 하드웨어에 따라 압축 된 것이므로 이미 압축 된 5GB JPG는 더 압축되지 않지만 일반적으로 5GB의 텍스트는 압축.

그렇다면 왜 이것을 하드 드라이브에 사용하지 않는 것입니까? harddrive에 너무 많은 로직이 필요할 수도 있고, 하드 드라이브를 너무 많이 가열하는 데 너무 취약 할 수도 있고, 원하는 경우 데이터를 명시 적으로 압축하기가 너무 쉽습니다. 어쩌면 그것은 몇몇 드라이브를 위해 존재합니까?

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.