프로그램의 크기가 왜 그렇게 큰가요?

빈티지 프로그램 인 Netscape Navigator 또는 초기 버전의 Microsoft Word를 보면 이러한 프로그램의 크기는 50MB 미만입니다. 이제 Google 크롬을 설치할 때 200MB이고 데스크톱 버전의 Slack은 300MB입니다. 프로그램이 사용 가능한 모든 메모리를 얼마나 많이 사용하든 그 이유는 무엇인지에 대한 규칙을 읽었습니다.

현재의 프로그램 크기가 10 년 또는 15 년 전에 비해 너무 큰 이유는 무엇입니까? 프로그램은 더 많은 기능을 수행하지 않으며 크게 다르게 보이지 않습니다. 자원 돼지 란 무엇입니까?

"매우 다른 것을 보는 것"은 인식의 문제입니다. 오늘날의 그래픽은 예전과는 완전히 다른 화면 해상도를 유지해야합니다. 결과적으로 로고보다 충분히 좋은 100x100 이미지는 이제 끔찍하게 볼 수 있습니다. 그것은 같은 것의 1000x1000 이미지로 대체되어야했는데, 그것은 바로 100 배입니다. (대신 벡터 그래픽을 사용할 수 있다는 것을 알고 있지만 요점을 강조합니다. 벡터 그래픽 렌더링 코드는 이전에 필요하지 않은 시스템에 추가해야했기 때문에 한 종류의 크기 증가와의 타협입니다. 다른 사람에게.)

"다른 방식으로 일하는 것"도 마찬가지로 인식의 문제입니다. 오늘의 브라우저는 않습니다 대규모 1995에서 하나 (. 하나 비오는 날 역사적인 노트북으로 인터넷 서핑을 시도 - 당신이 거의 사용할 수 없게입니다 찾을 수 있습니다)보다 더 많은 일을 그들 중 많은 사람들이 아주 많이 사용되는 것은 아닙니다 및 사용은 90 완전히 인식 될 수있다 그들 중 %,하지만 거기에 있습니다.

물론 공간에 대한 최적화와 새로운 기능 도입에 더 많은 시간을 투자하는 경향이 있습니다. 이것은 모든 사람을위한 더 크고 더 빠르고 저렴한 컴퓨터의 자연스러운 부작용입니다. 그렇습니다. 1990 년과 같이 리소스 효율적인 프로그램을 작성할 수 있으며 결과는 놀라 울 정도로 빠르고 매끄 럽습니다. 그러나 더 이상 비용 효율적이지 않습니다. 브라우저를 완료하는 데 10 년이 걸리며,이 때 요구 사항이 완전히 변경되었습니다. 사람들은 작년에 느리고 작은 기계로 인해 효율성을 높이기 위해 프로그래밍에 익숙해졌으며 다른 사람들도 그 일을하고있었습니다. 즉시이 변경된 것으로, 프로그램의 성공을위한 병목 실행할 수있는에서 이동 전혀 실행에점점 더 반짝이는 것들이 있습니다 . 그리고 우리가 지금있는 곳입니다.

Netscape Navigator를 최신 브라우저와 비교하면 기능에 큰 차이가 있습니다. 그냥 비교 HTML 3.2 (I가 인쇄 미리보기를 수행 할 때 51 페이지)을 함께 사양을 현재 HTML 사양 (PDF 버전은 1155 페이지입니다). 크기가 20 배 증가했습니다.

Netscape Navigator에는 DOM이없고 CSS가 없습니다! DOM이나 스타일 시트를 수정하는 JavaScript, 문서는 동적으로 변경되지 않았습니다. 탭이 없습니다. 오디오 나 비디오가 없습니다. 최신 브라우저는 훨씬 더 복잡한 프로그램입니다.

한 가지 이유는 응용 프로그램 내에 패키지 된 데이터의 해상도와 품질이 높기 때문에 더 큽니다. Netscape 시절의 아이콘은 최대 32x32 픽셀이었으며 최대 8 비트 깊이 (아마도 4) 였지만 지금은 64x64와 같으며 투명도의 진정한 색상으로 32 비트 깊이를 의미합니다. 16 배 더 큽니다. 공간이 너무 저렴하여 사람들이 PNG를 생성 할 때 "압축"옵션을 확인하지 않아도됩니다.

또 다른 이유는 오늘날의 응용 프로그램은 이전 응용 프로그램과 달리 엄청난 양의 데이터를 가지고 있기 때문입니다. 응용 프로그램에게 "시작"프리젠 테이션과 함께 제공받을 오늘이 존재하는 비디오를 .

또 다른 이유는 오늘날 프로그래밍 언어가 각각 100MB의 조율에 이르는 풍부한 런타임 환경과 함께 사용되는 경향이 있기 때문입니다. 런타임 환경의 모든 기능을 사용하지 않더라도 모든 것을 앱과 함께 패키지해야합니다.

그러나 주된 이유는 오늘날 응용 프로그램에서 사용할 수있는 수많은 라이브러리가 존재하고 휠의 지속적인 재발 명을 피하기 위해 라이브러리를 사용하는 문화를 개발했기 때문입니다. 물론 라이브러리를 사용하기 시작하면 몇 가지 질문이 나타나고 가장 자유로운 답변을 제공하는 습관을 개발했습니다.

• 내 함수 중 하나에서만 사용하려는 경우 다른 라이브러리를 포함시킬 가치가 있습니까? - 네

• 해당 라이브러리에서 제공하는 전체 기능의 작은 하위 집합 만 필요한 경우 또 다른 라이브러리를 포함시킬 가치가 있습니까? - 네

• 이 라이브러리를 포함 시켜서 2 일의 작업만으로 나를 구할 수 있다면 또 다른 라이브러리를 포함시킬 가치가 있습니까? - 네

• 급여에 따라 다른 프로그래머가 이미 다른 라이브러리에 익숙해 져 있기 때문에 거의 동일한 목적을 제공하는 여러 라이브러리를 포함시키는 것이 가치가 있습니까? - 네

  (나는 단지 이러한 경향을 관찰하고 있으며, 내가 동의하는지 또는 동의하지 않는지에 대해서는 진술하지 않습니다.)

언급 할 가치가 또 다른 이유는 몇 가지 선택 사이에서 사용할 응용 프로그램을 결정하려고 할 때, 일부 사용자가 있다는 것입니다 생각하는 더 많은 공간을 차지하는 일이 물론 완전한 넌센스 더 기능이 포장해야합니다 애호가 그래픽 등 (될 것 .)

결론적으로 소프트웨어는 가스처럼 행동합니까? 사용 가능한 모든 공간을 차지하는 경향이 있습니까? 어떤 의미에서는 그렇습니다. 우리는 우리의 드라이브에서 대부분의 공간을 차지 것을 보면, 우리의 대부분의 대답은 응용 프로그램이 아니라 영화와 음악 등의 미디어 등이다 훨씬 . 스토리지 용량이 늘어나는 것과 같은 속도로 소프트웨어가 부풀어 오르지 않았으며 앞으로도 그럴 것 같지 않으므로 향후 응용 프로그램은 사용자가 사용할 수있는 스토리지 공간 의 무시할만한 부분 을 나타낼 것 입니다.

10 년 전 다른 답변에 추가하여 일반적으로 현지화 된 / 국제화 된 버전을위한 별도의 버전이있었습니다. 이제는 프로그램이 프로그램 버전을 채우는 모든 출시 버전에 전체 지역화 지원을 번들로 제공하는 경우가 일반적입니다.

한 가지 이유는 종속성입니다. 풍부한 기능과 외관이 좋은 프로그램에는 암호화, 맞춤법 검사, XML 및 JSON 작업, 텍스트 편집 및 기타 여러 가지 작업이 많이 필요합니다. 그들은 어디에서 왔을 까? 어쩌면 당신은 당신의 자신의 롤과 가능한 작게 유지합니다. 대부분 실제로는 필요하지 않은 많은 기능을 가진 타사 구성 요소 (MIT 라이센스 오픈 소스)를 사용하지만 타사 구성 요소에서 단일 기능이 필요하면 전체 구성 요소를 자주 가져와야합니다. 따라서 더 많은 종속성을 추가하고 그 자체에 의존하는 프로그램이 발전하고 성장함에 따라 의존도도 커집니다.

그래픽 / 유용성이 실제로 요인이되는 반면, 라이브러리 / 과도하게 컴파일 된 코드는 엄청나게 많습니다.

작은 코드가 여전히 가능한 예 : MenuetOS, 단일 플로피 디스크에 맞는 강력한 앱을 갖춘 완전한 64 비트 OS.

명백한 이유없이 큰 코드를 사용할 수있는 방법의 예 : 간단한 텍스트 출력 "Hello, World!" 최근에 아이다에서. 컴파일 된 실행 파일이 1 MiB! 이상이었습니다. 어셈블리의 동일한 실행 파일은 KiB 또는 2입니다 (일부 실행 파일은 실제 실행 코드는 수십 바이트입니다).

사용자와 사용 가능한 하드웨어라는 두 가지 사항에 맞게 소프트웨어를 구축해야한다는 것은 명백한 사실입니다. 사용자가 원하는 하드웨어로 적시에 원하는 것을 수행하는 경우 프로그램은 그 목적에 적합합니다. 잘 했어 그러나 하드웨어가 기본적으로 모든 측정 가능한 차원에서 향상됨에 따라 적합하지 않은 것에서 적합으로 이동하는 개별 프로그램의 수가 증가합니다. 설계 공간이 더 커집니다.

• 수준 높은 언어를 사용하면 이전보다 적은 코드와 시간으로 아이디어를 표현할 수 있습니다. 반대로 복잡성이 줄어듦에 따라 점점 더 복잡한 아이디어를 표현할 수있게되었습니다.
• 응용 프로그램에 더 많은 데이터를 번들로 제공 하면 즉시 더 유용하게 사용할 수 있습니다. 예를 들어, 맞춤법 검사 응용 프로그램이 인류에게 알려진 모든 언어와 번들로 제공되기까지는 그리 오래 걸리지 않을 것입니다. 결국 몇 기가 바이트에 불과합니다.
• 하드웨어 트레이드 오프를 통해 개발자와 사용자는 자신이 관심을 갖는 리소스를 더 많이 선택할 수 있습니다. FLAC / OGG vs WAV, SVG vs PNG, 데이터베이스 인덱스를 참조하십시오.
• 휴먼 인터페이스는 종종 이전에 막대한 양의 하드웨어에 사용되는 기능을 유용성으로 교환합니다. 앤티 앨리어싱, 고해상도, 빠른 새로 고침 및 개별 패널 양을 스 와이프하면보다 사실적이고 직관적이며 관련성이 높은 경험을 얻을 수 있습니다.

이것은 안드로이드 응용 프로그램과 관련이 있습니다. 4 년 전, 간단한 앱은 약 2-5MB의 공간을 차지했습니다. 오늘날 간단한 앱은 약 10-20MB의 공간을 차지합니다.

사용 가능한 공간이 많을수록 앱 크기가 커집니다.

안드로이드의 경우 두 가지 주요 이유가 있다고 생각합니다.

• 구글은 안드로이드 프레임 워크를 확장하고 많은 새로운 기능을 추가했다.

• 개발자는 더 이상 신경 쓰지 않습니다. 이미지는 훨씬 더 높은 해상도 (물론 스마트 폰 화면 해상도가 증가)에 포함되어 있으며 타사 라이브러리는 무의식적으로 포함되어 있습니다.

많은 시간이 개발자 시간과 그 시간의 비용으로 귀결됩니다. Visual Basic이 처음 등장했을 당시에는 C / C ++와 경쟁하고 있었고, 이에 대한 큰 노크는 Windows 용 ANSI C에서 15K 정도의 'Hello World'를 작성할 수 있다는 것입니다. VB의 문제점은 항상 300K 런타임 라이브러리의 배설물을 가지고 있다는 것입니다.

이제 VB 프로그램 크기의 10 배가 될 수 있으며 여전히 K보다 약간 더 크지 만 C / C ++ 프로그램의 크기는 10 배이며 몇 달 동안 더 많은 개발이 진행되고 있습니다.

결국 응용 프로그램의 부풀림은 개발 생산의 엄청난 도약, 가격의 감소 및 구식 개발 시대에는 불가능했던 광범위한 기능을 지불하는 작은 가격입니다. 프로그램이 작고 빠르지 만 약한 경우 서로 호환되지 않으며 기능이 부족하고 개발 비용이 많이 든다.

시간이 지남에 따라 사용자의 요구는 계속 발전하고 점점 더 까다로워 지므로 서로 다른 소프트웨어의 공급 업체 / 작성자는 경쟁의 이름으로 이러한 요구를 충족시켜야합니다.

그러나 새로운 요구를 충족한다는 것은 종종 새로운 코드를 추가하는 것을 의미합니다. 새로운 코드는 수정해야 할 새로운 취약점을 의미합니다. 새로운 취약점을 해결하면 새로운 취약점에 코드가 추가되거나 문이 열릴 수 있습니다.

사용자의 요구를 충족시키기 위해 추가 된 각 기능에는 속도에 더 많은 프로세서 성능 (모두이 브라우저 나 브라우저의 속도에 대해 불평 함), 더 나은 시각 효과를위한 새로운 그래픽 리소스 등이 필요할 수 있습니다.

이 모든 것은 새로운 계층의 애플리케이션 (코드), 보안 및 때로는 하드웨어를 추가하는 것을 의미합니다.

많은 크기는 내장 라이브러리에서 비롯됩니다. 요즘 많은 응용 프로그램은 응용 프로그램과 함께 많은 양을 묶는 전자를 사용하여 만들어졌습니다. Linux에 응용 프로그램을 설치하는 경우 다른 응용 프로그램에서도 사용중인 공유 라이브러리를 통해 많은 응용 프로그램이 이미 설치되어 있기 때문에 일반적으로 훨씬 더 작습니다.

소프트웨어를 작성할 때 기능 A가 필요한 경우 모듈 A *를 가져옵니다. A *는 A를 해결할 수 있지만 A *는 A보다 많은 문제를 해결할 수 있으며 A *는 클 수 있습니다. 모든 대형 모듈은 대형 소프트웨어를 만듭니다.

같은 경우는 아니지만 다음과 같은 경우가 있습니다. Java를 사용하여 콘솔에서 "hello world"를 인쇄해야하는 경우 JRE (> 60MB)가 설치되어 있어야합니다.

Java 예제가 좋지 않은 경우 다음 중 하나를 시도하십시오. 소프트웨어가 파일에 로깅해야하는 경우, 로깅 모듈을 사용하여 데이터베이스, 네트워크 및 기타 다른 기능을 통해 실제로 로그를 작성할 수 있지만 함수는 절대로 사용되지 않습니다. 프로젝트.

프로그램이 사용 가능한 모든 메모리를 얼마나 많이 사용하든 그 이유는 무엇인지에 대한 규칙을 읽었습니다.

사실이 아닙니다. 시스템은 운영 체제에 메모리가 부족해질 때까지 사용한 메모리를 해제하지 않습니다. 이것은 성능 향상입니다. 이미지가있는 페이지를 탐색하는 경우 멀리 탐색합니다. 다시 탐색 할 수 있으므로 이미지가 다시 필요합니다. 운영 체제에 RAM이있는 경우 다시 필요하지 않을 때까지 메모리를 지우지 않아도됩니다.

메모리를 즉시 비우면 응답 성이 높은 웹 페이지가 화면에 표시되기를 원할 때 CPU주기와 메모리 대역폭이 사용자로부터 멀어지게됩니다.

운영 체제는 사용 가능한 모든 비 응용 프로그램 메모리를 사용하며 대부분은 파일 시스템 캐시 용입니다.

메모리 관리는 어려운 문제이지만 항상 일을하는 매우 영리한 사람들이 있습니다. 의도적으로 낭비되는 것이 없으며 주요 목표는 매우 반응이 빠른 컴퓨터를 제공하는 것입니다.

프로그램이 가용 공간을 채우기 위해 확장되는 경향이있을 수 있습니다. 교외 현상과 비슷하게 그리드로 연결된 초 고속도로에 새로운 차선을 추가하고 몇 년 안에 교통량이 다시 백업됩니다.

그러나 당신이 그것을 조사하면 당신은 그들이 실제로 더 많은 일을한다는 것을 알 수 있습니다. 예를 들어 더 멋진 그래픽을 실행하는 브라우저에는 몇 년 전에는 없었던 매끄러운 개발자 도구가 있습니다. 또한 일부 라이브러리를 사용하여 코드의 일부만 사용하는 경우도 있습니다. 따라서 프로그램은 사용 가능한 메모리를 채우기 위해 크기가 커질 수 있지만 그 중 일부는 합법적 인 이유 일 수 있습니다.

최적화되지 않은 객체를 기반으로 구축 된 라이브러리는로드, 설치 및 더 많은 컴퓨팅주기를 위해 더 많은 메모리가 필요합니다. 객체 코드는 대부분 부풀어 오릅니다.

표준 C ++ 코드 실행을 단계별로 실행하여 모든 assert () 객체 호출이 유효한 객체인지 확인하십시오. 객체를 캡슐화하는 객체의 레이어에 레이어를 디자인하면 언더 레이어가 부풀어 오릅니다. 프로그래머는 필요한 기능으로 제한되는 것을 재 설계하는 것보다 빠르기 때문에 게으르고 더 많은 객체를 가져옵니다. 정말 간단합니다.

Linux C 커널의 크기 (커널 만)와 맞춤형 응용 프로그램의 크기를 고려하십시오. 커널은 전체 머신을 실행할 수 있습니다. 그러나 응용 프로그램처럼 빠르게 구축되지 않았으므로 최상의 기능을 만드는 데 시간이 오래 걸립니다.