Tại sao kích thước của các chương trình rất lớn?

Nếu chúng ta xem chương trình cổ điển Netscape Navigator hoặc phiên bản đầu tiên của Microsoft Word, các chương trình đó có kích thước dưới 50 MB. Bây giờ khi tôi cài đặt google chrome, nó là 200 MB và phiên bản Slack dành cho máy tính để bàn là 300 MB. Tôi đọc về một số quy tắc rằng các chương trình sẽ chiếm hết bộ nhớ khả dụng cho dù nó có giá bao nhiêu nhưng tại sao?

Tại sao kích thước hiện tại của các chương trình quá lớn so với 10 hoặc 15 năm trước? Các chương trình không thực hiện nhiều chức năng hơn và trông không khác lắm. Bây giờ nó là tài nguyên gì?

"Nhìn rất khác" là một vấn đề về nhận thức. Đồ họa ngày nay phải trông đẹp ở độ phân giải màn hình hoàn toàn khác so với trước đây, với kết quả là hình ảnh 100x100 trước đây đủ tốt để logo trở nên trông khủng khiếp. Nó đã phải được thay thế bằng một hình ảnh 1000x1000 của cùng một thứ, đó là một yếu tố của 100 ngay tại đó. (Tôi biết bạn có thể sử dụng đồ họa vector thay thế, nhưng điều đó chỉ nhấn mạnh vào mã kết xuất đồ họa vector đã được thêm vào các hệ thống không cần đến nó trước đây, vì vậy đây chỉ là sự đánh đổi từ một loại tăng kích thước cho người khác.)

"Làm việc khác nhau" cũng là một vấn đề về nhận thức. Trình duyệt hiện nay không ồ ạt điều nhiều hơn một từ năm 1995. (Hãy thử lướt internet với một máy tính xách tay di tích lịch sử một ngày mưa -. Bạn sẽ tìm thấy nó gần như không sử dụng được) Không nhiều trong số họ đang được sử dụng rất nhiều, và việc sử dụng có thể hoàn toàn không biết gì về 90 % trong số họ, nhưng họ ở đó.

Trên hết, tất nhiên, là xu hướng chung dành ít thời gian hơn cho việc tối ưu hóa mọi thứ cho không gian và nhiều hơn nữa để giới thiệu các tính năng mới. Đây là một tác dụng phụ tự nhiên của máy tính lớn hơn, nhanh hơn, rẻ hơn cho mọi người. Vâng, có thể viết các chương trình có hiệu quả tài nguyên như năm 1990, và kết quả sẽ rất nhanh và lắt léo. Nhưng nó sẽ không còn hiệu quả nữa; trình duyệt của bạn sẽ mất mười năm để hoàn thành, khi đó các yêu cầu sẽ hoàn toàn thay đổi. Mọi người thường lập trình hết sức chú ý đến hiệu quả vì máy móc nhỏ, chậm của năm qua buộc họ phải làm như vậy và mọi người khác cũng đang làm điều đó. Ngay khi điều này thay đổi, nút cổ chai cho sự thành công của chương trình đã chuyển từ khả năng chạy tất cả sang chạyngày càng nhiều thứ sáng bóng , và đó là nơi chúng ta đang ở.

Nếu bạn so sánh Netscape Navigator với một trình duyệt hiện đại, có một sự khác biệt lớn về chức năng. Chỉ cần so sánh Thông số HTML 3.2 (51 trang khi tôi thực hiện bản xem trước in) với Thông số HTML hiện tại (phiên bản PDF là 1155 trang). Đó là kích thước tăng gấp 20 lần.

Netscape Navigator không có DOM và không có CSS! Không có thay đổi động của tài liệu, không có JavaScript sửa đổi DOM hoặc biểu định kiểu. Không có tab. Không có âm thanh hoặc video. Một trình duyệt hiện đại là một bao la chương trình phức tạp hơn.

Một lý do là dữ liệu được đóng gói trong các ứng dụng lớn hơn vì chúng có độ phân giải và chất lượng cao hơn. Một biểu tượng trở lại thời của Netscape có nhiều nhất là 32x32 pixel, với độ sâu tối đa 8 bit, (có thể chỉ 4,) trong khi bây giờ nó có thể giống như 64x64 và nó có màu thật với độ trong suốt, nghĩa là độ sâu 32 bit. Đó là lớn hơn 16 lần. Và không gian rẻ đến mức mọi người thường không thèm kiểm tra tùy chọn "nén" khi tạo PNG.

Một lý do khác là các ứng dụng ngày nay mang theo một lượng dữ liệu khổng lồ với chúng, điều mà các ứng dụng cũ không có. Ngày nay, có các ứng dụng được phát hành cùng với phần trình bày "bắt đầu" trong video .

Một lý do khác là các ngôn ngữ lập trình ngày nay có xu hướng đi đôi với môi trường thời gian chạy phong phú, khá lớn, với tốc độ 100 MB mỗi ngôn ngữ. Ngay cả khi bạn không sử dụng tất cả các tính năng của môi trường thời gian chạy, bạn vẫn phải đóng gói toàn bộ với ứng dụng của mình.

Nhưng lý do chính là ngày nay tồn tại hàng tấn thư viện ngoài kia mà chúng ta có thể sử dụng trong các ứng dụng của mình và chúng tôi đã phát triển văn hóa sử dụng các thư viện để tránh việc phát minh lại bánh xe liên tục. Tất nhiên, một khi bạn bắt đầu sử dụng các thư viện, một số câu hỏi sẽ xuất hiện và chúng tôi đã phát triển thói quen đưa ra câu trả lời tự do nhất cho họ:

• Có đáng để bao gồm một thư viện khác nếu nó chỉ được sử dụng bởi một trong các chức năng của tôi không? - vâng.

• Có đáng để bao gồm một thư viện khác không nếu tôi chỉ cần một tập hợp con nhỏ của toàn bộ sự giàu có của chức năng mà thư viện đó cung cấp? - vâng.

• Có đáng để bao gồm một thư viện khác nếu việc bao gồm nó sẽ chỉ giúp tôi tiết kiệm được sau 2 ngày làm việc? - vâng.

• Có đáng để bao gồm nhiều thư viện phục vụ cùng một mục đích chỉ vì các lập trình viên khác nhau trong bảng lương của tôi đã quen thuộc với các thư viện khác nhau? - vâng.

  (Xin lưu ý rằng tôi chỉ đang quan sát những xu hướng này, tôi không đưa ra tuyên bố nào về việc tôi đồng ý hay không đồng ý với chúng.)

Một lý do đáng nói khác là khi cố gắng quyết định sử dụng ứng dụng nào trong số một số lựa chọn, một số người dùng nghĩ rằng ứng dụng chiếm nhiều không gian hơn sẽ có nhiều tính năng hơn, sẽ có đồ họa fancier, v.v. .)

Vì vậy, để kết luận, phần mềm có hành xử như khí? Liệu nó có xu hướng chiếm tất cả không gian có sẵn cho nó? Trong một ý nghĩa nhất định có, nhưng không đến mức đáng báo động. Nếu chúng ta nhìn vào những gì chiếm nhiều dung lượng nhất trên ổ đĩa của chúng tôi, đối với hầu hết chúng ta câu trả lời là nó không phải là các ứng dụng, nhưng phương tiện truyền thông như phim ảnh và âm nhạc cho đến nay . Phần mềm đã không phình to với cùng tốc độ mà dung lượng lưu trữ đã được mở rộng và không chắc là nó sẽ như vậy, vì vậy trong các ứng dụng trong tương lai có thể sẽ chiếm một phần không đáng kể của không gian lưu trữ dành cho người dùng.

Ngoài các phiên bản khác, 10 năm trước thường có các phiên bản riêng cho các phiên bản được bản địa hóa / quốc tế hóa. Bây giờ, nói chung là các chương trình sẽ gói hỗ trợ bản địa hóa đầy đủ vào mọi phiên bản được phát hành có kích thước chương trình.

Một lý do là sự phụ thuộc. Một chương trình có chức năng phong phú và ngoại hình đẹp cần rất nhiều thứ được thực hiện - mã hóa, kiểm tra chính tả, làm việc với XML và JSON, chỉnh sửa văn bản và nhiều thứ khác. Họ sẽ đến từ đâu? Có thể bạn tự cuộn và giữ chúng nhỏ nhất có thể. Nhiều khả năng bạn sử dụng các thành phần của bên thứ ba (có lẽ là nguồn mở được MIT cấp phép) có rất nhiều chức năng mà bạn không bao giờ thực sự cần nhưng một khi bạn cần một chức năng duy nhất từ ​​một thành phần bên thứ ba, bạn thường phải mang theo toàn bộ thành phần. Vì vậy, bạn thêm ngày càng nhiều phụ thuộc và khi chính chúng phát triển và phát triển chương trình của bạn, điều đó phụ thuộc vào chúng cũng phát triển.

Mặc dù đồ họa / khả năng sử dụng thực sự là những yếu tố góp phần, nhưng có rất nhiều trong số đó là thư viện / mã được biên dịch dư thừa.

Ví dụ về cách mã nhỏ vẫn có thể là: MenuetOS, HĐH 64 bit đầy đủ với các ứng dụng mạnh mẽ phù hợp với một đĩa mềm.

Ví dụ về cách mã lớn có thể không có lý do rõ ràng: Tôi đã thực hiện một đầu ra văn bản đơn giản "Xin chào, Thế giới!" ở Ada gần đây. Tập tin thực thi được biên dịch là hơn 1 MiB!. Cùng thực thi trong lắp ráp chỉ là một KiB hoặc 2 (và phần lớn trong số đó là chi phí thực thi, mã chạy thực tế là hàng chục byte).

Thật sự tầm thường rằng phần mềm phải được xây dựng để phù hợp với hai điều: Người dùng và phần cứng có sẵn. Một chương trình phù hợp với mục đích của nó nếu nó thực hiện những gì người dùng muốn một cách kịp thời với phần cứng theo ý của người dùng. Vâng duh. Nhưng khi phần cứng cải thiện về cơ bản tất cả các kích thước có thể đo được, số lượng chương trình rời rạc chuyển từ không phù hợp sang tăng - không gian thiết kế trở nên lớn hơn:

• Các ngôn ngữ cấp cao hơn cho phép thể hiện ý tưởng theo ít mã & thời gian hơn trước. Điều này làm giảm độ phức tạp, ngược lại, làm cho nó có thể thể hiện những ý tưởng ngày càng phức tạp.
• Gói nhiều dữ liệu hơn với ứng dụng có thể khiến nó có thể sử dụng được ngay lập tức. Ví dụ, có lẽ sẽ không còn lâu nữa trước khi các ứng dụng kiểm tra chính tả đi kèm với mọi ngôn ngữ mà nhân loại biết đến - rốt cuộc, nó chỉ có vài gigabyte.
• Sự đánh đổi phần cứng cho phép các nhà phát triển và người dùng có nhiều sự lựa chọn hơn trong đó họ quan tâm đến tài nguyên nào. Xem ví dụ FLAC / OGG vs WAV, SVG vs PNG, các chỉ mục cơ sở dữ liệu.
• Các giao diện nhân đạo thường đánh đổi những gì trước đây sẽ chiếm số lượng lớn phần cứng để sử dụng. Chống răng cưa, độ phân giải cao, làm mới nhanh và vuốt giữa số lượng cho các bảng rời rạc, tất cả tạo nên trải nghiệm chân thực hơn, do đó trực quan và dễ hiểu hơn.

Điều này hoàn toàn đúng liên quan đến các ứng dụng Android. Bốn năm trước, một ứng dụng đơn giản chiếm khoảng 2-5 megabyte. Ngày nay, một ứng dụng đơn giản chiếm khoảng 10-20 megabyte.

Càng có nhiều không gian, kích thước ứng dụng càng lớn.

Tôi nghĩ rằng có hai lý do chính trong trường hợp của Android:

• Google mở rộng khung Android, bổ sung rất nhiều chức năng mới.

• Các nhà phát triển không quan tâm nữa. Hình ảnh được bao gồm ở độ phân giải cao hơn nhiều (tất nhiên độ phân giải màn hình điện thoại thông minh tăng lên), các thư viện của bên thứ ba được bao gồm một cách thiếu suy nghĩ.

Rất nhiều trong số đó rút ngắn thời gian của nhà phát triển và chi phí của thời gian đó. Quay trở lại những ngày khi Visual Basic lần đầu tiên xuất hiện, nó đã cạnh tranh với C / C ++ và điều gây tiếng vang lớn là bạn có thể viết 'Hello World' trong ANSI C cho Windows trong khoảng 15K. Vấn đề với VB là bạn luôn có thư viện thời gian chạy 300K.

Bây giờ, bạn có thể tăng gấp 10 lần kích thước chương trình VB của mình và nó sẽ vẫn chỉ là một vài K nữa, nhưng gấp 10 lần kích thước của chương trình C / C ++ của bạn và bạn đang xem xét một vài MONTHS phát triển hơn.

Cuối cùng, sự phình to của các ứng dụng của bạn là một cái giá nhỏ để trả cho những bước nhảy vọt trong sản xuất phát triển, giảm giá và vô số khả năng chưa từng có trong những ngày phát triển thủ công cũ; khi các chương trình nhỏ và nhanh nhưng cũng yếu, không tương thích với nhau, thiếu tính năng và tốn kém để phát triển.

Theo thời gian, nhu cầu của người dùng đang phát triển và ngày càng khắt khe hơn, vì vậy nhà cung cấp / tác giả của các phần mềm khác nhau buộc phải đáp ứng những nhu cầu đó dưới danh nghĩa cạnh tranh.

Nhưng đáp ứng một nhu cầu mới có nghĩa là thường thêm mã mới. Mã mới có nghĩa là lỗ hổng mới để sửa chữa. Sửa các lỗ hổng mới có thể thêm mã hoặc mở cửa cho các lỗ hổng mới.

Mỗi tính năng được thêm vào để đáp ứng nhu cầu của người dùng có thể cần nhiều sức mạnh bộ xử lý hơn cho tốc độ (tất cả chúng ta đều phàn nàn về tốc độ của trình duyệt này hoặc trình duyệt đó), tài nguyên đồ họa mới cho hiệu ứng hình ảnh tốt hơn ... vv.

Tất cả điều này có nghĩa là thêm các lớp ứng dụng mới (mã), bảo mật và đôi khi là phần cứng.

Rất nhiều kích thước đến từ các thư viện được xây dựng. Nhiều ứng dụng ngày nay được xây dựng bằng cách sử dụng electron, gói một lượng lớn với ứng dụng. Nếu bạn cài đặt các ứng dụng trên Linux, chúng thường nhỏ hơn nhiều vì phần lớn ứng dụng đã được cài đặt thông qua các thư viện dùng chung mà các chương trình khác cũng đang sử dụng.

Khi xây dựng phần mềm, nếu bạn cần chức năng A, bạn sẽ nhập mô-đun A *. A * có thể giải quyết A, nhưng A * có thể giải quyết nhiều vấn đề hơn A và A * có thể lớn. Tất cả các mô-đun lớn dẫn đến phần mềm kích thước lớn.

Có thể không giống trường hợp tương tự, nhưng đại loại như thế này: Nếu bạn chỉ cần in "hello world" trên bảng điều khiển bằng Java, bạn cần cài đặt JRE (> 60MB).

Nếu ví dụ về Java không tốt, hãy thử điều này: Nếu phần mềm cần đăng nhập vào tệp, nó có thể sử dụng mô-đun ghi nhật ký thực sự có thể tạo nhật ký cho cơ sở dữ liệu, qua mạng và một số tính năng khác, nhưng các chức năng không bao giờ được sử dụng trong dự án.

Tôi đọc về một số quy tắc rằng các chương trình sẽ chiếm hết bộ nhớ khả dụng cho dù nó có giá bao nhiêu nhưng tại sao?

Điều đó không hoàn toàn đúng. Các hệ thống sẽ không giải phóng bộ nhớ mà chúng đã tiêu thụ cho đến khi hệ điều hành chịu áp lực bộ nhớ. Đây là một cải tiến hiệu suất. Nếu bạn đang duyệt một trang có hình ảnh trên, bạn điều hướng đi. Bạn có thể điều hướng trở lại, do đó cần hình ảnh một lần nữa. Nếu hệ điều hành có RAM, sẽ không có điểm nào trong việc xóa bộ nhớ cho đến khi bạn chắc chắn rằng mình sẽ không cần nó nữa.

Việc xóa bộ nhớ ngay lập tức sẽ làm mất chu kỳ CPU và băng thông bộ nhớ khỏi người dùng khi họ có thể rất muốn các trang web có độ phản hồi cao được hiển thị trên màn hình.

Hệ điều hành sẽ tiêu thụ tất cả bộ nhớ không có sẵn của ứng dụng, phần lớn trong số đó là cho bộ đệm của hệ thống tệp.

Quản lý bộ nhớ là một vấn đề khó khăn nhưng có những người rất thông minh làm việc về nó mọi lúc. Không có gì bị lãng phí vào mục đích và mục tiêu chính là cung cấp cho bạn một máy tính rất nhạy.

Có thể đúng là các chương trình có xu hướng mở rộng để lấp đầy không gian có sẵn, tương tự như hiện tượng ngoại ô nơi bạn thêm làn đường mới vào đường cao tốc bị chặn và trong một vài năm, giao thông sẽ được sao lưu lại.

Nhưng nếu bạn nhìn vào nó, bạn có thể thấy rằng các chương trình của họ thực sự làm được nhiều thứ hơn. Các trình duyệt, ví dụ, chạy đồ họa fancier, có các công cụ dành cho nhà phát triển bóng bẩy không tồn tại vài năm trước, v.v. Họ cũng liên kết với nhiều thư viện, đôi khi chỉ sử dụng một phần nhỏ mã. Vì vậy, trong khi các chương trình có thể tăng kích thước để lấp đầy bộ nhớ khả dụng, một số trong đó có thể là lý do chính đáng.

Các thư viện được xây dựng trên các đối tượng không được tối ưu hóa đòi hỏi nhiều bộ nhớ hơn để tải, cài đặt và nhiều chu kỳ tính toán hơn để hoạt động. Mã đối tượng là cho hầu hết các phần phình ra.

Chỉ cần bước qua mã C ++ tiêu chuẩn đang chạy để xem tất cả các lệnh gọi đối tượng ed assert () để đảm bảo chúng là các đối tượng hợp lệ. Khi bạn thiết kế lớp trên lớp đối tượng bao bọc các đối tượng, lớp lót bên dưới bị phồng lên và mờ đục. Các lập trình viên trở nên lười biếng và tiếp nhận nhiều đối tượng hơn vì nó nhanh hơn việc thiết kế lại những gì giới hạn trong chức năng cần thiết. Nó thực sự đơn giản.

Hãy xem xét kích thước của hạt nhân Linux C, chỉ là hạt nhân, so với kích thước của các ứng dụng bespoke. Nhân có thể chạy toàn bộ máy. Nhưng nó không được xây dựng nhanh như các ứng dụng, cần có thời gian để tạo ra chức năng tốt nhất.