कार्यक्रमों के आकार इतने बड़े क्यों हैं?

185

यदि हम विंटेज प्रोग्राम नेटस्केप नेविगेटर या माइक्रोसॉफ्ट वर्ड के शुरुआती संस्करण को देखते हैं, तो वे प्रोग्राम 50 एमबी से कम आकार के थे। अब जब मैं गूगल क्रोम स्थापित करता हूं तो यह 200 एमबी है और स्लैक का डेस्कटॉप संस्करण 300 एमबी है। मैंने कुछ नियम के बारे में पढ़ा कि कार्यक्रम सभी उपलब्ध स्मृति को ले जाएगा चाहे वह कितना भी हो लेकिन क्यों?

10 या 15 साल पहले की तुलना में कार्यक्रमों के वर्तमान आकार इतने बड़े क्यों हैं? कार्यक्रम बहुत अधिक कार्य नहीं कर रहे हैं और बहुत अलग नहीं दिखते हैं। वह क्या है जो अब संसाधन हॉग है?

programming-practices files delivery

— निकलैस रोसेंक्रंट्ज़
स्रोत

134

केवल 4 गुना आकार ?! यह आश्चर्यजनक है कि एक आधुनिक ब्राउज़र कितना अधिक विचार करता है

— रिचर्ड टिंगल

23

एक साइड नोट के रूप में, मुझे विश्वास है कि 'कुछ नियम है कि प्रोग्राम सभी उपलब्ध मेमोरी को ले लेंगे चाहे वह कितना भी हो लेकिन क्यों?' शायद भौतिक डिस्क स्थान के बजाय यादृच्छिक अभिगम स्मृति को संदर्भित करता है, कम से कम यह मेरी व्याख्या होगी। गलत हो सकता है।

— Trotski94

103

तो आप क्या कह रहे हैं कि एक कार्यक्रम है कि एक बार $ 10 मूल्य की हार्ड डिस्क की जगह अब लगभग 30 सेंट हार्ड डिस्क की जगह लेता है? मुझे यह चिंता करना कठिन लगता है।

— एरिक लिपर्ट

49

"कार्यक्रम बहुत अधिक कार्य नहीं कर रहे हैं" - अच्छा भगवान आदमी। बस HTML 4 कल्पना और CSS 1 युक्ति पर ध्यान दें (चिंता न करें, मैं प्रतीक्षा करूँगा - यदि आप उन्हें पढ़ते हैं तो भी आपको लंबा समय नहीं लगेगा)। नेटस्केप 4 उन लोगों को ठीक से लागू करने का प्रबंधन भी नहीं करता था। क्रोम का समर्थन करता है कि बस नए और पागल HTML और सीएसएस की राशि। साथ ही इसमें टैब हैं। और हर छह सप्ताह में खुद को अपडेट करता है।

— पॉल डी। वेट

13

Btw। नेटस्केप समय में 50 एमबी बड़ा था, लेकिन, रिकॉर्ड के लिए, इसमें न केवल वेब ब्राउज़र, बल्कि मेल क्लाइंट और HTML संपादक भी शामिल थे, और शायद कुछ और भी।

— el.pescado

265

"बहुत अलग दिखना" एक धारणा का विषय है। आज के ग्राफिक्स को पूरी तरह से अलग-अलग स्क्रीन रिज़ॉल्यूशन पर देखने में अच्छा लगता है, जिसका वे उपयोग करते थे, इस परिणाम के साथ कि एक 100x100 छवि जो किसी लोगो के लिए पर्याप्त से अधिक अच्छा हुआ करती थी, अब भयानक रूप से निपटने के लिए दिखाई देगी। इसे उसी चीज़ की 1000x1000 की छवि के साथ बदलना पड़ा है, जो कि 100 का कारक है। (मुझे पता है कि आप इसके बजाय वेक्टर ग्राफिक्स का उपयोग कर सकते हैं, लेकिन यह सिर्फ इस बात पर जोर देता है - वेक्टर ग्राफिक्स रेंडरिंग कोड को उन प्रणालियों में जोड़ा जाना चाहिए जिनकी पहले आवश्यकता नहीं थी, इसलिए यह केवल एक प्रकार के आकार में वृद्धि से व्यापार-बंद है अन्य को।)

"अलग तरीके से काम करना" इसी तरह धारणा का विषय है। आज का ब्राउज़र बड़े पैमाने पर 1995 से एक से अधिक चीजें करता है। (एक बरसात के दिन एक ऐतिहासिक लैपटॉप के साथ इंटरनेट पर सर्फिंग करें - आप पाएंगे कि यह लगभग बेकार है।) उनमें से बहुत से उपयोग नहीं किए जाते हैं, और उपयोग पूरी तरह से 90 से अनजान हो सकते हैं। उनमें से%, लेकिन वे वहाँ हैं।

इसके शीर्ष पर, निश्चित रूप से, अंतरिक्ष के लिए चीजों के अनुकूलन पर कम समय बिताना और नई विशेषताओं को पेश करने की सामान्य प्रवृत्ति है। यह सभी के लिए बड़े, तेज, सस्ते कंप्यूटरों का एक प्राकृतिक दुष्प्रभाव है। हां, उन कार्यक्रमों को लिखना संभव होगा जो संसाधन-कुशल हैं जैसे कि वे 1990 में थे, और परिणाम आश्चर्यजनक रूप से तेज और चालाक होगा। लेकिन यह अब और प्रभावी नहीं होगा; आपके ब्राउज़र को पूरा होने में दस साल लगेंगे, जिस समय तक आवश्यकताएँ पूरी तरह से बदल गई होंगी। लोग दक्षता के लिए अत्यधिक ध्यान देने के साथ कार्यक्रम करते थे, क्योंकि yesteryear की धीमी, छोटी मशीनों ने उन्हें मजबूर किया, और बाकी सभी भी ऐसा कर रहे थे। जैसे ही यह बदल गया, कार्यक्रम की सफलता के लिए अड़चन सभी को चलाने में सक्षम होने से स्थानांतरित हो गईअधिक से अधिक चमकदार चीजें , और यही वह जगह है जहां हम अब हैं।

— किलियन फोथ
स्रोत

120

आधुनिक ब्राउज़र में जिन चीजों के ठोस उदाहरण शामिल होने चाहिए उनमें क्रिप्टो लाइब्रेरी, यूनिकोड डेटाबेस, जावास्क्रिप्ट रनटाइम और सभी समर्थित MIME प्रकारों के लिए जटिल रेंडरिंग इंजन और पार्सर के अलावा JIT कंपाइलर, वीडियो कोडेक्स, एक पीडीएफ रेंडरर का अनुकूलन शामिल होगा। यह जोड़ देता है, लेकिन गेम ब्राउज़रों के विपरीत उच्च रिज़ॉर्ट परिसंपत्तियों की बहुत आवश्यकता नहीं है। एक आधुनिक फ़ायरफ़ॉक्स डाउनलोड केवल 40-50MB संकुचित होता है।

— amon

23

"परिणाम आश्चर्यजनक रूप से तेज़ और धीमा होगा" - इच्छाधारी सोच जैसा लगता है।

— डॉक ब्राउन

16

@amon यह मत भूलो कि ब्राउज़रों में अन्य प्रकार के resourses और प्लगइन्स के लिए संपूर्ण API और क्या-क्या नहीं हैं। वे डिबगिंग टूल (प्रोफाइलर, नेटवर्क एनालिस्ट, तत्व निरीक्षक, एक पूरी तरह कार्यात्मक कंसोल, डीबगर्स और एक टन अधिक) के साथ भी आते हैं। ब्राउजर एक संपूर्ण ऑपरेटिंग सिस्टम के करीब पहुंच रहे हैं, जिसकी हम सभी कल्पना कर सकते हैं। वेब असेंबली का उपयोग करने के लिए एक ऑन-गोइंग चर्चा भी है! ओपी को बकवास के टन से चकित होना चाहिए वे एक ब्राउज़र में रटना कर सकते हैं।

— इस्माईल मिगुएल

10

@IsmaelMiguel जहां तक Chrome OS का संबंध है, ब्राउज़र पहले से ही एक संपूर्ण ऑपरेटिंग सिस्टम हैं। ; पप

— अजेदी 32

111

tendency to spend less time on optimizing things for space इस। जब मैं कोड लिखता हूं, तो मैं अंतरिक्ष या गति के लिए अनुकूलन नहीं करता हूं। मैं रखरखाव के लिए अनुकूलन। यह अधिक महत्वपूर्ण है कि कोडबेस तेज या छोटे होने की तुलना में आसानी से बदल सकता है। मैं उम्मीद कर सकता हूं कि कार्यक्रम की गति के बारे में हर शिकायत के लिए, मुझे नई सुविधाओं के लिए दस अनुरोध और इसे छोटा बनाने के लिए शून्य अनुरोध मिलेगा।

— user2023861 14

108

यदि आप नेटस्केप नेविगेटर की तुलना एक आधुनिक ब्राउज़र से करते हैं, तो कार्यक्षमता में भारी अंतर है। बस HTML 3.2 युक्ति की तुलना करें (जब मैं एक पृष्ठ का पूर्वावलोकन करता हूँ तो 51 पृष्ठ) वर्तमान HTML युक्ति के साथ (पीडीएफ संस्करण 1155 पृष्ठ है)। यह आकार में 20 गुना वृद्धि है।

नेटस्केप नेविगेटर के पास DOM नहीं था और CSS नहीं थी! दस्तावेज़ के कोई गतिशील परिवर्तन नहीं थे, कोई भी जावास्क्रिप्ट डोमेन या स्टाइल-शीट को संशोधित नहीं करता था। कोई टैब नहीं। कोई ऑडियो या वीडियो नहीं। एक आधुनिक ब्राउज़र एक बहुत अधिक जटिल कार्यक्रम है।

— JacquesB
स्रोत

12

हां, हाल के ब्राउज़र एनिमेशन, ग्रेडिएंट, इमेज फिल्टर इफेक्ट्स, जावास्क्रिप्ट, 2 डी ग्राफिक्स (कैनवास), 3 डी ग्राफिक्स वेबलॉग, ऑडियो जनरेशन, गेमपैड (!), वीडियो डिकोडिंग, उन्नत क्लाइंट-साइड-स्टोरेज, पीयर-टू-पीयर संचार के साथ करते हैं! (WebRTC), जियोलोकेशन, वेबसॉकेट, वेब क्रिप्टोग्राफी, मिडी, माइक / वेब कैमरा, सूचनाओं तक पहुंच, आदि

— ysdx

1

और अधिक सामान (DOM, CSS, Javascript) करने के साथ अधिक अचल संपत्ति (कई मॉनिटर्स, रिज़ॉल्यूशन में बड़े पैमाने पर वृद्धि: कंप्यूटर स्क्रीन का बड़ा होना: 1999 से 2011 तक ) - 800x600 बनाम 1920x1080 बनाम 4k ... 8k और उससे आगे ... 1080 से 4 k संकल्प को चौगुना कर रहा है ... 8k फिर से चौगुना है।

— वर्नरसीडी

7

@WernerCD बस एक बड़ी स्क्रीन होने से बड़े बाइनरी की आवश्यकता नहीं होती है। 64 बाय 64 पिक्सेल, 32 बिट आइकन को डिस्क पर समान स्थान की आवश्यकता होगी चाहे वह 800x600 या 2560x1440 मॉनिटर पर प्रदर्शित हो। अपनी विंडो को आकार देने से बाइनरी का आकार नहीं बदलता है। डिस्प्ले के साथ क्या मायने रखता है जब आप पिक्सेल दोहरीकरण जैसे सामान करना शुरू करते हैं, तो आपको तेज (एर) को जारी रखने के लिए बड़े संसाधनों की आवश्यकता होती है।

— 8bittree

1

@ 8bittree, यह सॉफ्टवेयर प्रदर्शन पर अधिक मांग रख सकता है। और अधिक प्रदर्शन करने वाला कोड अधिक जटिल हो सकता है (उदाहरण के लिए कैनवस का उपयोग करने वाली वेबसाइट को एसवीजी का उपयोग करने की तुलना में अधिक जटिलता और कोड की आवश्यकता होती है)। लेकिन हाँ, आप ज्यादातर सही हैं।

— पॉल ड्रेपर

1

हालांकि यह निश्चित रूप से सच है कि वर्तमान HTML HTML 3.2 की तुलना में बहुत अधिक है, विनिर्देशन स्वयं भी बहुत अधिक विस्तृत है जो महत्वपूर्ण मात्रा में सामग्री को जोड़ता है। एचटीएमएल 3.2 की EMतत्व के विवरण की लंबाई की तुलना करें - एक पूर्ण आठ या नौ शब्द - एचटीएमएल 5 कल्पना में उसी की लंबाई के साथ - मेरे लिए, तत्व का वर्णन करने वाले आस-पास की सामग्री सहित एक स्क्रीनफुल से अधिक, जहां यह लागू है और इसका इच्छित उपयोग क्या है।

— बजे एक CVn

79

एक कारण यह है कि अनुप्रयोगों के भीतर पैक किया गया डेटा बड़ा है क्योंकि वे उच्च रिज़ॉल्यूशन और गुणवत्ता वाले हैं। नेटस्केप के दिनों में एक आइकन सबसे अधिक 32x32 पिक्सेल पर था, जिसमें अधिकतम 8 बिट गहराई, (संभवतः केवल 4) थी, जबकि अब यह संभवतः 64x64 जैसा है और यह पारदर्शिता के साथ सही रंग में है, जिसका अर्थ है 32 बिट गहराई। वह 16 गुना बड़ा है। और अंतरिक्ष इतना सस्ता है कि लोग अक्सर पीएनजी उत्पन्न करते समय "संपीड़ित" विकल्प की जांच करने से भी बाज नहीं आते हैं।

एक और कारण यह है कि आजकल अनुप्रयोग अपने साथ डेटा की एक मनमौजी राशि ले जाते हैं, जो पुराने अनुप्रयोग नहीं करते थे। आज ऐसे एप्लिकेशन मौजूद हैं जो वीडियो में "आरंभ करना" प्रस्तुति के साथ एक साथ भेज दिए जाते हैं ।

एक और कारण यह है कि प्रोग्रामिंग भाषाएं आज समृद्ध रन-टाइम वातावरण के साथ मिलकर चलती हैं, जो कि काफी बड़ी हैं, प्रत्येक 100MB की धुन पर। यहां तक कि अगर आप अपने रन-टाइम वातावरण की सभी विशेषताओं का उपयोग नहीं करते हैं, तो भी आपको अपने ऐप के साथ पूरी चीज़ को पैकेज करना होगा।

लेकिन मुख्य कारण यह है कि आज वहां मौजूद टन और टन पुस्तकालय बाहर हैं जिन्हें हम अपने अनुप्रयोगों में उपयोग कर सकते हैं, और हमने पहिया के निरंतर अविष्कार से बचने के लिए पुस्तकालयों का उपयोग करने की संस्कृति विकसित की है। बेशक, एक बार जब आप पुस्तकालयों का उपयोग करना शुरू करते हैं, तो कई सवाल उठते हैं, और हमने सबसे उदार उत्तर देने की आदत विकसित की है:

क्या यह अभी तक एक और पुस्तकालय को शामिल करने के लायक है अगर यह मेरे केवल एक फ़ंक्शन द्वारा उपयोग किया जा रहा है? - हाँ।
क्या यह अभी तक एक और पुस्तकालय को शामिल करने के लिए लायक है अगर मुझे केवल उस पुस्तकालय द्वारा दी गई कार्यक्षमता की पूरी संपत्ति के एक छोटे से उपसमूह की आवश्यकता है? - हाँ।
क्या यह अभी तक एक और पुस्तकालय को शामिल करने के लायक है अगर इसका समावेश मुझे केवल 2 दिनों के काम से बचाएगा? - हाँ।
क्या यह कई पुस्तकालयों को शामिल करने के लायक है जो कमोबेश एक ही उद्देश्य से काम करते हैं क्योंकि मेरे पेरोल पर अलग-अलग प्रोग्रामर पहले से ही अलग-अलग पुस्तकालयों से परिचित होते हैं? - हाँ।

(कृपया ध्यान दें कि मैं सिर्फ इन प्रवृत्तियों का पालन कर रहा हूं, मैं इस बात पर कोई बयान नहीं दे रहा हूं कि क्या मैं सहमत हूं या उनसे सहमत नहीं हूं।)

उल्लेख के लायक एक और कारण यह है कि कई विकल्पों में से किस अनुप्रयोग का उपयोग करने का निर्णय लेने की कोशिश करते समय, कुछ उपयोगकर्ता सोचते हैं कि जो अधिक स्थान घेरता है वह अधिक फ़ीचर-पैक होगा, उसके पास कट्टर ग्राफिक्स होंगे, आदि (जो पूरी तरह से बकवास है, ज़ाहिर है) ।)

तो, निष्कर्ष निकालने के लिए, क्या सॉफ्टवेयर गैस की तरह व्यवहार करता है? क्या यह इसके लिए उपलब्ध सभी जगह पर कब्जा कर सकता है? एक निश्चित अर्थ में हाँ, लेकिन किसी भी खतरनाक हद तक नहीं। अगर हम क्या हमारे ड्राइव पर सबसे स्थान में समा जाता को देखो, हम में से ज्यादातर के लिए जवाब है कि यह आवेदन पत्र नहीं है, लेकिन फिल्मों और संगीत के रूप में मीडिया में इस तरह है अब तक । सॉफ़्टवेयर उसी दर पर ब्लोटिंग नहीं कर रहा है जो भंडारण क्षमता का विस्तार कर रहा है, और यह संभावना नहीं है कि यह कभी होगा, इसलिए भविष्य के अनुप्रयोगों में उपयोगकर्ताओं के लिए उपलब्ध भंडारण स्थान के एक नगण्य अंश का प्रतिनिधित्व करने की संभावना है ।

— माइक नाकिस
स्रोत

17

यह सही जवाब है। (वर्तमान में) उच्च श्रेणी की टिप्पणियों में अधिक कार्यक्षमता का उल्लेख है, लेकिन यह पूरी तरह से बढ़े हुए आकार की व्याख्या नहीं करता है। आकार शामिल पुस्तकालयों से आता है जो उन कार्यों को प्रदान करते हैं।

— user1936

5

@IsmaelMiguel अच्छी तरह से, मैं नियमित उपयोगकर्ताओं के बारे में बात कर रहा था। इसके अलावा, खेल एक विशेष मामला है, क्योंकि ये 35GB ज्यादातर मीडिया हैं, न कोड, न ही लाइब्रेरी। यह सिर्फ मीडिया के लिए होता है कि आप केवल एक विशेष एप्लिकेशन के माध्यम से देख सकते हैं, जो कि खेल है। लेकिन एक गेमर के लिए, 35 जीबी आज के मल्टी-टेराबाइट ड्राइव पर कुछ भी नहीं है। किसी भी तरह, मान लें कि यदि आप एक गेमर हैं जो एक छोटी ड्राइव के मालिक होने पर जोर देते हैं तो आप कहीं भी बाहर के उपयोगकर्ताओं के प्रतिनिधि के पास नहीं हैं।

— माइक नाकिस

2

@MikeNakis हर गेमर के पास 1TB ड्राइव या 256GB SSD खरीदने के लिए पैसे नहीं होते हैं। मेरे जैसे कुछ लोगों के पास 128GB SSD या 500GB से कम वाला लैपटॉप है। कुछ समय पहले, मेरे एसएसडी अंतरिक्ष उपयोग का 80% खेल बस था। यह जगह खाने के लिए, बस 3-4 गेम था। और खेल में ही, लगभग सभी के पास एक लैपटॉप है और उस पर खेलता है।

— इस्माइल मिगुएल

5

@ मायके ओह, इससे कोई फर्क नहीं पड़ता। जब हम किसी एप्लिकेशन के आकार की बात करते हैं तो हमारा मतलब है कि डाउनलोड करने योग्य इंस्टॉलेशन फ़ाइल का आकार, या डिस्क पर एप्लिकेशन द्वारा कब्जे में लिया गया कुल स्थान। इसमें लाइब्रेरी, मीडिया, डेटा, सब कुछ शामिल है। और आजकल, असंगति के मुद्दों से बचने के लिए, एप्लिकेशन आमतौर पर अधिकांश पुस्तकालयों के साथ मिलकर जहाज करते हैं जिनकी उन्हें आवश्यकता होती है, बजाय यह उम्मीद करने के कि पुस्तकालय पहले से ही स्थापित होंगे, और सही संस्करण के होंगे, आदि मुख्य निष्पादन योग्य फ़ाइल का आकार। न किसी हित का, न किसी परिणाम का।

— माइक नकीस

3

@IsmaelMiguel एक प्रोग्रामर के लिए, यह उनके अलग-अलग वर्चुअल मशीन, डॉकटर कंटेनर और इस तरह की संभावना है। पूरे फूला हुआ सिस्टम गुणा करने से बेहतर कोई ब्लोट नहीं है ;-)

— सेमीस्टर

16

अन्य आवारों के अतिरिक्त, 10 साल पहले आम तौर पर स्थानीयकृत / अंतर्राष्ट्रीयकृत संस्करणों के लिए अलग-अलग संस्करण होते थे। अब यह आम तौर पर ऐसा होता है कि प्रोग्राम हर जारी किए गए संस्करण में पूर्ण स्थानीयकरण समर्थन को बंडल करेंगे जो प्रोग्राम के आकार को पैड करता है।

— Eterm
स्रोत

5

मैं गलत हो सकता हूं, लेकिन मैं इस भ्रम के तहत काम कर रहा हूं कि तार इस समस्या का सबसे कम हिस्सा हैं। सच है, वहाँ बहुत सारी भाषाएँ हैं, लेकिन फिर भी एक उपयोगकर्ता द्वारा देखे गए तार की मात्रा बहुत सीमित है। आखिरकार, आपके उपयोगकर्ता इंटरफ़ेस में विफल होने का सबसे महत्वपूर्ण तरीका बहुत अधिक पाठ शामिल करना है।

— सेमास्टर

5

@Cmaster ने जो कहा, उसे जोड़ते हुए, फ़ायरफ़ॉक्स विशेष रूप से पूर्ण स्थानीयकरण को बंडल नहीं करता है (और जब मैं इसके बारे में सोच रहा हूं, तो न तो किसी भी तरह का।)

— BenjiWiebe

2

@cmaster स्ट्रिंग्स, नहीं। लेकिन स्थानीय वीडियो और ऑडियो, विशेष रूप से खेल के संदर्भ में? IIRC एक 60 जीबी गेम (GTA V?) था जहां> 10 जीबी पूरी तरह से स्थानीयकृत ऑडियो था। यह एक महत्वपूर्ण हिस्सा है।

— बॉब

@ याकूब राइट, मैं खेलों के बारे में नहीं सोच रहा था, वे मुझे लिखे गए एक बड़े अपवाद लगते हैं।

— सेमीस्टर

प्रत्येक भाषा के लिए, स्ट्रिंग तालिका कुछ अतिरिक्त K बाइट्स तक जोड़ सकती है। केवल एप्लिकेशन आइकन अकेले आम तौर पर सभी स्ट्रिंग सामग्री के कुल आकार को बौना करते हैं (संभावित अपवाद एम्बेडेड शब्दकोशों के साथ आवेदन किए जा रहे हैं)

— andyb

13

एक कारण निर्भरता है। रिच फंक्शनलिटी और अच्छे लुक्स वाले एक प्रोग्राम के लिए बहुत सी चीजों की जरूरत होती है - एन्क्रिप्शन, स्पेल चेकिंग, एक्सएमएल और जेएसएन के साथ काम करना, टेक्स्ट एडिटिंग और बहुत सारी चीजें। वे कहां से आएंगे? हो सकता है कि आप अपना रोल करें और उन्हें जितना संभव हो उतना छोटा रखें। सबसे अधिक संभावना है कि आप तीसरे पक्ष के घटकों का उपयोग करते हैं (MIT लाइसेंस प्राप्त खुला स्रोत शायद) जिसकी बहुत अधिक कार्यक्षमता है जिसे आपको वास्तव में कभी भी ज़रूरत नहीं है, लेकिन एक बार आपको तीसरे पक्ष के घटक से एकल फ़ंक्शन की आवश्यकता होती है जिसे आपको अक्सर पूरे घटक को ले जाना पड़ता है। इसलिए आप अधिक से अधिक निर्भरताएँ जोड़ते हैं और जैसा कि वे स्वयं विकसित होते हैं और आपके प्रोग्राम को बढ़ाते हैं जो उन पर निर्भर करता है, बढ़ता है।

— sharptooth
स्रोत

मैं थोड़े उत्सुक हूं कि इस वजह से रातों-रात दो डाउनवॉट मिल गए।

— शार्पूथ

6

मैंने नहीं किया, लेकिन मुझे नहीं लगता कि यह वास्तव में पर्याप्त गहराई से सवाल का जवाब देता है। यह बहुत कुछ कहता है "सॉफ़्टवेयर बड़ा हो जाता है क्योंकि यह अधिक सामान करता है", और आप अन्य उत्तरों से देखेंगे कि वास्तव में इससे कहीं अधिक है।

— ऑर्बिट

1

एक संबंधित कारक यह है कि सिस्टम में जो स्थैतिक लिंकिंग का उपयोग करते हैं, एक लिंकर को केवल कोड में खींचने की आवश्यकता हो सकती है जो वास्तव में उपयोग किया जाता है [कुछ लिंकर हमेशा हर चीज में खींच लेंगे, लेकिन बेहतर लोग चयनात्मक होने की कोशिश करते हैं]। डायनेमिक लिंकिंग का उपयोग करते समय, विशेष रूप से यदि मॉड्यूल साझा किया जा सकता है, भले ही पहला कोड जो मॉड्यूल स्थापित करता है, उसे केवल एक फ़ंक्शन की आवश्यकता होती है, यह जानने का कोई तरीका नहीं है कि मॉड्यूल को साझा करने के लिए अन्य कोड द्वारा क्या फ़ंक्शन की आवश्यकता हो सकती है।

— सुपरकैट

@ शेराप्यूट मुझे अब और आश्चर्य नहीं है। जबकि ज्यादातर मामलों में सिस्टम काम करता है मैं भी बुरी तरह से टूटे हुए उत्तर देखता हूं, पागलों की तरह उठते हैं और स्वीकार किए जाते हैं, जबकि सही लोगों को भी सभी में गुमनामी में उतारा जाता है ...

— ब्रायन नोबलाच

10

हालांकि ग्राफिक्स / प्रयोज्य वास्तव में कारकों का योगदान कर रहे हैं, लेकिन इसका एक बहुत बड़ा कारण यह है कि पुस्तकालय / अतिरिक्त संकलित कोड है।

छोटा कोड कैसे हो सकता है, इसका उदाहरण: मेनूसेट, एक शक्तिशाली फ़्लॉपी डिस्क पर फिट होने वाले शक्तिशाली एप्लिकेशन के साथ 64-बिट ओएस।

बिना किसी स्पष्ट कारण के कितना बड़ा कोड हो सकता है इसका उदाहरण: मैंने एक सरल पाठ आउटपुट किया "हैलो, वर्ल्ड!" हाल ही में Ada में। संकलित निष्पादन योग्य 1 MiB से अधिक था। असेंबली में एक ही निष्पादन योग्य बस एक KiB या 2 है (और इसका एक बड़ा भाग निष्पादन योग्य है, वास्तविक चल रहा कोड दसियों बाइट्स है)।

— ब्रायन नॉब्लुच
स्रोत

3

फ्लॉपी डिस्क क्या है? ;)

— 500 - आंतरिक सर्वर त्रुटि

@ ५००-इंटरनलसेवरर्रार क्या है एडा? : डी

— बेनजीवेबे

3

नवागंतुकों के लिए, फ्लॉपी डिस्क लगभग 1.4 MiB

— सर्ज बोर्स्च

3

मैंने 200 बाइट्स के तहत आधुनिक एडीए एक्जीक्यूटिव देखे हैं। लेकिन अगर आपका कंपाइलर डिफ़ॉल्ट रूप से फुल टास्किंग रनटाइम जैसी चीजों में खींच लेता है, चाहे आप कार्यों का उपयोग करते हैं या नहीं, तो 1MB या तो उम्मीद की जानी है। और यह आमतौर पर इसे नीचे छोड़ने की परेशान करने लायक नहीं है।

— ब्रायन ड्रमंड बाद

@BrianDrummond, वास्तव में भद्दे रनटाइम, या गंदे रनटाइम और लाइब्रेरी और लिंकर की तरह लगता है। एक प्रशिक्षण वीडियो में मैंने कई साल पहले देखा था, जीन इचबाहा एट अल ने उल्लेख किया था कि एक सामान्य एडा रनटाइम (भाषा के मूल संस्करण के लिए) लगभग 4K होगा। जिज्ञासा से बाहर, मैंने तिवारी 320C30 रनटाइम पैकेज के खिलाफ यह जाँच की। वह पैसे पर सही था।

— जॉन आर। स्ट्रोह

7

यह पूरी तरह से सच है कि सॉफ्टवेयर को दो चीजों को फिट करने के लिए बनाया जाना है: उपयोगकर्ता और उपलब्ध हार्डवेयर। एक कार्यक्रम अपने उद्देश्य के लिए फिट है अगर यह वह करता है जो उपयोगकर्ता उपयोगकर्ता के निपटान में हार्डवेयर के साथ समय पर चाहता है। खैर दुह। लेकिन जैसा कि हार्डवेयर मूल रूप से सभी औसत दर्जे के आयामों में सुधार करता है, असत्य कार्यक्रमों की संख्या जो अयोग्य से फिट तक बढ़ जाती है - डिजाइन स्थान बहुत बड़ा हो जाता है:

उच्च स्तर की भाषाएं पहले की तुलना में कम कोड और समय में विचारों को व्यक्त करना संभव बनाती हैं। यह कम जटिलता, इसके विपरीत, तेजी से जटिल विचारों को व्यक्त करना संभव बनाता है।
एप्लिकेशन के साथ अधिक डेटा को बंडल करने से यह तुरंत अधिक उपयोगी हो सकता है। उदाहरण के लिए, यह संभव नहीं होगा कि वर्तनी जांचने से पहले अनुप्रयोग मानवता के लिए जाने जाने वाली हर भाषा के साथ बंडल हो - यह केवल कुछ गीगाबाइट्स हैं, आखिरकार।
हार्डवेयर ट्रेड-ऑफ डेवलपर्स और उपयोगकर्ताओं को अधिक पसंद करते हैं जिसमें वे किस संसाधन की परवाह करते हैं। उदाहरण के लिए देखें FLAC / OGG बनाम WAV, SVG बनाम PNG, डेटाबेस इंडेक्स।
मानव इंटरफेस अक्सर व्यापार बंद कर देता है जो पहले प्रयोज्य के लिए भारी मात्रा में हार्डवेयर की राशि होता है। एंटी-अलियासिंग, उच्च रिज़ॉल्यूशन, तेज़ रिफ्रेशिंग, और स्वाइपिंग के बीच की मात्राएँ जो असतत पैनलों के लिए होती हैं, वे अधिक यथार्थवादी और इसलिए सहज और सापेक्ष, अनुभव के लिए बनाते हैं।

— l0b0
स्रोत

6

Android एप्लिकेशन के विषय में यह निश्चित रूप से सही है। चार साल पहले, एक साधारण ऐप ने लगभग 2-5 मेगाबाइट स्थान लिया। आजकल एक साधारण ऐप लगभग 10-20 मेगाबाइट जगह लेता है।

जितना अधिक स्थान उपलब्ध होगा, ऐप का आकार उतना ही बड़ा होगा।

मुझे लगता है कि Android के मामले में दो मुख्य कारण हैं:

Google ने Android ढांचे का विस्तार किया, बहुत सी नई कार्यक्षमता जोड़ी।
डेवलपर्स अब परवाह नहीं करते हैं। छवियाँ उच्चतर रिज़ॉल्यूशन में शामिल होती हैं (निश्चित रूप से स्मार्टफ़ोन स्क्रीन रिज़ॉल्यूशन में वृद्धि हुई है), तृतीय-पक्ष लाइब्रेरी विचारहीन रूप से शामिल हैं।

— Mike76
स्रोत

1

वह अंतिम गोली बिंदु बिल्कुल सही है।

— ऑर्बिट

3

मैंने कुल एक Android ऐप बनाया है, और APK 0.05MB है। तो फिर, यह इतना नहीं करता है। मैं अभी भी सोच रहा हूं कि एक स्टॉपवॉच ऐप (मेरी जैसी कार्यक्षमता के साथ, हालांकि पूरी तरह से अलग है) कई एमबी लेती है।

— इमिबिज़

5

अंतिम बुलेट बिंदु गलत है, डेवलपर्स देखभाल करते हैं। हमें बस विभिन्न प्राथमिकताओं को टटोलना है और उस ऐप को थोड़ा बड़ा करना है।

— NPSF3000

यह भी मदद नहीं करता था कि एसडीके (उस समय) ने मेरे 0.05 एमबी ऐप में 5 + एमबी लाइब्रेरी जोड़ने पर जोर दिया था, जिसकी मुझे ज़रूरत नहीं थी, और मुझे रिलीज से पहले इसे हटाने के लिए याद रखना था।

— इबिबिस

4

इसका बहुत सारा विकास समय और उस समय की लागत को उबालता है। उन दिनों में जब दृश्य बेसिक पहली बार दृश्य पर आया था, यह C / C ++ के साथ प्रतिस्पर्धा कर रहा था और इसके खिलाफ बड़ी दस्तक यह थी कि आप शायद 15K में विंडोज के लिए ANSI C में 'हैलो वर्ल्ड' लिख सकते थे। VB के साथ समस्या यह थी कि आपके पास हमेशा 300K रनटाइम लाइब्रेरी का अल्बाट्रॉस था।

अब, आप अपने VB प्रोग्राम का आकार 10x कर सकते हैं और यह अभी भी केवल कुछ K अधिक होगा, लेकिन 10x आपके C / C ++ प्रोग्राम का आकार और आप कुछ MONTHS अधिक विकास देख रहे हैं।

अंत में आपके अनुप्रयोगों का ब्लोट विकास उत्पादन में भारी छलांग, कीमत में कमी और क्षमताओं की व्यापक विविधता के लिए भुगतान करने के लिए एक छोटी सी कीमत है जो विकास के पुराने हाथ से तैयार किए गए दिनों में कभी भी संभव नहीं होगा; जब कार्यक्रम छोटे और तेज थे, लेकिन कमजोर, एक-दूसरे के साथ असंगत, कम-चित्रित और विकसित करने के लिए महंगा।

— andyb
स्रोत

2

यह पोस्ट पढ़ना मुश्किल है (पाठ की दीवार)। आप आपत्ति तो नहीं है संपादित एक बेहतर आकार में यह ing?

— gnat

1

हैलो वर्ल्ड के "10x आकार" के लिए "महीनों में अधिक विकास" की आवश्यकता होती है? क्या एक महीने तक मिरर नॉनस्टॉप के सामने दस बार अपने दांतों को ब्रश करना शामिल है?

— ई.पू.

दांतों को बार-बार ब्रश करना x का रैखिक कार्य है, लेकिन प्रोग्रामिंग आम तौर पर रैखिक कार्य नहीं है। यदि आप सबसे निम्न स्तर के भाषा फ़ंक्शंस का उपयोग करके कोड की प्रत्येक पंक्ति को नियंत्रित करते हैं, तो आपको तेज़ और छोटे कोड मिलते हैं, लेकिन उच्च स्तर की जटिलता के स्तर पर। उच्च स्तर की भाषाएं अधिक फूलती हैं लेकिन लागत को जटिलता के रैखिक कार्य के करीब रखती हैं।

— एंडीब

2

समय के साथ, उपयोगकर्ता की आवश्यकताएं विकसित हो रही हैं और अधिक से अधिक मांग हो रही है, इसलिए विभिन्न सॉफ्टवेयर्स के विक्रेता / लेखक प्रतिस्पर्धा के नाम पर उन जरूरतों को पूरा करने के लिए मजबूर हैं।

लेकिन एक नई जरूरत को पूरा करने का मतलब है अक्सर नए कोड जोड़ना। नए कोड का मतलब है नई कमजोरियों को ठीक करना। नई कमजोरियों को ठीक करने से नई कमजोरियों के लिए कोड या खुले दरवाजे जुड़ सकते हैं।

उपयोगकर्ता की आवश्यकता को पूरा करने के लिए प्रत्येक अतिरिक्त सुविधा को गति के लिए अधिक प्रोसेसर शक्ति की आवश्यकता हो सकती है (हम सभी इस या उस ब्राउज़र की गति के बारे में शिकायत करते हैं), बेहतर दृश्य प्रभावों के लिए नए ग्राफिकल संसाधन ... आदि।

यह सब अनुप्रयोगों (कोड), सुरक्षा और कभी-कभी हार्डवेयर की नई परतों को जोड़ने का मतलब है।

0

बहुत सारे आकार पुस्तकालयों में निर्मित से आते हैं। इन दिनों कई अनुप्रयोगों को इलेक्ट्रॉन का उपयोग करके बनाया जाता है जो आवेदन के साथ एक बड़ी राशि का बंडल करता है। यदि आप लिनक्स पर एप्लिकेशन इंस्टॉल करते हैं तो वे आमतौर पर बहुत छोटे होते हैं क्योंकि एप्लिकेशन का अधिकांश हिस्सा पहले से ही साझा पुस्तकालयों के माध्यम से स्थापित होता है जो अन्य प्रोग्राम भी उपयोग कर रहे हैं।

— Qwertie
स्रोत

-1

सॉफ्टवेयर का निर्माण करते समय, यदि आपको फ़ंक्शन ए की आवश्यकता है, तो आप एक मॉड्यूल ए * आयात करेंगे। A * A को हल कर सकता है, लेकिन A * A से अधिक समस्याओं को हल कर सकता है, और A * बड़ा हो सकता है। सभी बड़े मॉड्यूल बड़े आकार के सॉफ़्टवेयर में परिणामित होते हैं।

शायद एक ही मामला नहीं है, लेकिन ऐसा कुछ है: यदि आपको जावा का उपयोग करके कंसोल पर "हैलो वर्ल्ड" प्रिंट करने की आवश्यकता है, तो आपको JRE (> 60MB) स्थापित करने की आवश्यकता है।

यदि जावा का उदाहरण अच्छा नहीं है, तो इसे आज़माएं: यदि सॉफ़्टवेयर को फ़ाइल करने के लिए लॉगिंग करने की आवश्यकता है, तो यह लॉगिंग मॉड्यूल का उपयोग कर सकता है जो वास्तव में डेटाबेस, ओवर नेटवर्क और कुछ अन्य विशेषताओं में लॉग बना सकता है, लेकिन फ़ंक्शन का उपयोग कभी नहीं किया जाता है परियोजना।

— neoedmund
स्रोत

क्यों वास्तव में 5 डाउनवोट हैं और एक भी टिप्पणी नहीं है जो यह समझाती है कि क्यों?

— क्रॉमास्टर

1

@KromStern पुस्तकालयों के काम करने के तरीके पर पहला खंड बहुत चमकता है, और असंगत रूप से उपयोग के साथ बहुत अस्पष्ट तरीके से ऐसा करता है code। मैं कहूंगा कि यह वास्तव में इस सवाल का जवाब नहीं है। दूसरा खंड जावा को एक उदाहरण के रूप में उपयोग करता है (हालांकि यह दावा करने की कोशिश की जा रही है कि JRE को एप्लिकेशन आकार के विकास का हिस्सा माना जाना चाहिए - जो फिर से प्रश्न के बिंदु को याद नहीं करता है और एक उचित उदाहरण नहीं है और इसे जारी रखना है जावा की गलतफहमी)। सभी में यह या तो गलत है, या पिछले, बेहतर लिखित, उत्तर में अंक दोहराता है।

1

नेटवर्क या फ़ाइल में प्रवेश करने का आपका उदाहरण या तो अच्छा नहीं है - क्योंकि कोड के दृष्टिकोण से, दोनों फाइलें हैं और बिल्कुल उसी तरह से हैंडल की जाती हैं (फ़ाइल और नेटवर्क के बीच का अंतर ऑपरेटिंग सिस्टम द्वारा नियंत्रित किया जाता है)। मुझे अभी तक एक लॉगिंग ढाँचा देखना है जो "डेटाबेस में लॉग" है इसकी मुख्य कार्यक्षमता के हिस्से के रूप में क्योंकि यह Oracle बनाम MySQL बनाम Sql सर्वर बनाम Postgres बनाम ... ड्राइवरों और द्वंद्वात्मक मतभेदों से जटिल होगा।

@ user40980 फ़ाइल और नेटवर्क के बीच का अंतर ऑपरेटिंग सिस्टम द्वारा नियंत्रित नहीं किया जाता है। उन्हें कनेक्ट करने और लिखने के लिए अलग-अलग OS कॉल की आवश्यकता होती है। डेटाबेस एक्सेस को JDBC या libdbi जैसी डेटाबेस स्वतंत्रता परत के माध्यम से नियंत्रित किया जाता है। (जो बदले में सभी अलग-अलग समर्थित डेटाबेस के लिए ड्राइवरों में खींच सकते हैं!)

— इबिबिस

-2

मैंने कुछ नियम के बारे में पढ़ा कि कार्यक्रम सभी उपलब्ध स्मृति को ले जाएगा चाहे वह कितना भी हो लेकिन क्यों?

यह बिल्कुल सच नहीं है। जब तक ऑपरेटिंग सिस्टम मेमोरी के दबाव में नहीं आता, तब तक सिस्टम द्वारा खपत की गई मेमोरी को सिस्टम जारी नहीं करेगा। यह एक प्रदर्शन में सुधार है। यदि आप छवियों के साथ एक पृष्ठ ब्राउज़ कर रहे थे, तो आप दूर जाते हैं। आप वापस नेविगेट कर सकते हैं, इसलिए फिर से छवि की आवश्यकता है। यदि ऑपरेटिंग सिस्टम में RAM है, तो मेमोरी को साफ़ करने का कोई मतलब नहीं है जब तक कि आप सुनिश्चित न हों कि आपको फिर से इसकी आवश्यकता नहीं होगी।

मेमोरी को तुरंत साफ़ करने से सीपीयू साइकल और मेमोरी बैंडविड्थ को उपयोगकर्ता से दूर ले जाएगा जब वे संभवतः सबसे अधिक उत्तरदायी वेब पेज स्क्रीन पर प्रदर्शित होने की इच्छा रखते हैं।

ऑपरेटिंग सिस्टम सभी उपलब्ध गैर-एप्लिकेशन मेमोरी का उपभोग करेगा, जिनमें से अधिकांश फ़ाइल सिस्टम कैश के लिए है।

मेमोरी प्रबंधन एक कठिन समस्या है लेकिन हर समय इस पर काम करने वाले बहुत चतुर लोग होते हैं। उद्देश्य पर कुछ भी बर्बाद नहीं किया जा रहा है और मुख्य लक्ष्य आपको एक बहुत ही उत्तरदायी कंप्यूटर प्रदान करना है।

— फिल हनेंट
स्रोत

3

यह बिल्कुल नहीं है कि वह क्या कह रहा है। वर्चुअल मेमोरी और कचरा संग्रह का आविष्कार तब किया गया था जब वह बोली लिखी गई थी, और वे व्यापक नहीं थे।

— जोर्ज डब्ल्यू मित्तग

-2

यह सच हो सकता है कि उपनगरीय घटना के समान उपलब्ध स्थान को भरने के लिए कार्यक्रमों का विस्तार होता है, जहां आप एक ग्रिडलॉक सुपरहाइवे में नई गलियों को जोड़ते हैं और कुछ वर्षों के भीतर यातायात फिर से बैकअप होता है।

लेकिन अगर आप इस पर गौर करते हैं, तो आप पा सकते हैं कि वे वास्तव में अधिक सामान बनाते हैं। ब्राउज़र, उदाहरण के लिए, फैन्सीयर ग्राफिक्स चलाते हैं, इसमें कुछ सालों पहले मौजूद डेवलपर डेवलपर स्लिक होते हैं, आदि, वे कई पुस्तकालयों से भी जुड़ते हैं, कभी-कभी कोड के सिर्फ एक छोटे हिस्से का उपयोग करते हैं। जब उपलब्ध स्मृति को भरने के लिए कार्यक्रम आकार में बढ़ सकते हैं, तो उनमें से कुछ वैध कारण हो सकते हैं।

— पॉल जे अबर्नथी
स्रोत

2

इस कुछ भी पर्याप्त पेशकश करने के लिए अंक बनाया और में पहले 13 जवाब में विस्तार से बताया नहीं लगता है

— कुटकी

-3

उन वस्तुओं पर निर्मित लाइब्रेरी जिन्हें अनुकूलित नहीं किया गया है उन्हें संचालित करने के लिए लोड करने, स्थापित करने और अधिक कंप्यूटिंग चक्रों के लिए अधिक मेमोरी की आवश्यकता होती है। ऑब्जेक्ट कोड अधिकांश भाग ब्लोट के लिए है।

मानक C ++ कोड के माध्यम से बस सभी मुखर () एड ऑब्जेक्ट कॉल को देखने के लिए चल रहा है ताकि यह सुनिश्चित हो सके कि वे वैध ऑब्जेक्ट हैं। जब आप ऑब्जेक्ट्स की परत पर परत डिज़ाइन करते हैं, तो ऑब्जेक्ट को थोपने वाले ऑब्जेक्ट्स को फूला हुआ और अपारदर्शी होता है। प्रोग्रामर आलसी हो जाते हैं और अधिक वस्तुओं को ले लेते हैं क्योंकि यह आवश्यक कार्यक्षमता तक सीमित होने की तुलना में तेज है। यह वास्तव में इतना आसान है।

लिनक्स सी कर्नेल के आकार पर विचार करें, बस कर्नेल, बीस्पोक अनुप्रयोगों के आकार के अनुसार। कर्नेल पूरी मशीन चला सकता है। लेकिन यह अनुप्रयोगों के रूप में जल्दी से नहीं बनाया गया था, सबसे अच्छी कार्यक्षमता बनाने के लिए धीरे-धीरे समय लगता है।

— daemondave
स्रोत