क्या जावास्क्रिप्ट या कई छोटे लोगों में एक बड़ी वस्तु होना बेहतर है?

Question

मैं एक जेएस लिब लिख रहा हूं जो शतरंज के खेल को फिर से बजाने योग्य गेम में बदलने के लिए पढ़ता है, एक ही वेब पेज में कई गेम (अपने स्वयं के div में) हो सकते हैं, जो मैं सोच रहा हूं - प्रदर्शन के बारे में सोच रहा है - यदि यह एक बड़ी वस्तु है जो सभी खेलों की सभी चालें या कई छोटी वस्तुओं को एक गेम की चालों को संग्रहित करने के लिए बेहतर है।

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

Answer 1

डोनाल्ड नुथ: "हम, छोटे क्षमता के बारे में भूल जाना चाहिए कहते हैं कि समय के 97%: समय से पहले अनुकूलन सब बुराई की जड़ है"

प्रारंभ अपने खेल के लिए एक डाटा मॉडल डिजाइन द्वारा यह सही है और एक डोमेन मॉडलिंग दृष्टिकोण से प्राकृतिक।

सॉफ़्टवेयर बनाएं।

फिर, जब आप विकास में एक मंच पर हैं जो प्रदर्शन का विश्लेषण करते हैं तो समझ में आता है, कुछ कम प्रदर्शन वातावरण तैयार करें जिन्हें आप अपने गेम में काम करना चाहते हैं, और उनमें परीक्षण करें।

आपको शायद कोई समस्या नहीं है, जैसा कि अन्य ने इस प्रश्न के उत्तर में कहा है।

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

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

Answer 2

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

Answer 3

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

मुझे लगता है कि आपको प्रत्येक गेम को शतरंज गेम ऑब्जेक्ट के उदाहरण (div) के रूप में सोचना चाहिए। यह अतिरिक्त विकास की सुविधा प्रदान करेगा, क्योंकि कस्टम लिब और गेम से निपटने के लिए कार्य करने के साथ-साथ आपको समग्र प्रदर्शन में वृद्धि करने के लिए प्रत्येक गेम ("वेब श्रमिकों के लिए Google) को थ्रेड करने की संभावना भी होगी।

Answer 4

छोटी वस्तुओं मेरी आंखों में बेहतर विकल्प हैं।

• एक सॉफ्टवेयर इंजीनियरिंग दृष्टिकोण से, यह छोटे, composable बजाय एक अखंड वस्तु वस्तुओं के साथ एक और अधिक मॉड्यूलर डिजाइन के लिए ज्यादा बेहतर है। प्रति गेम एक ऑब्जेक्ट रखने के बजाय, मैं प्रत्येक ऑब्जेक्ट को ऑब्जेक्ट के रूप में भी प्रस्तुत करता हूं।
• वी 8 जैसे हालिया जेएस इंजन "वर्ग" परिभाषाओं से संरचना-जैसी वस्तुओं को बनाने का प्रयास करते हैं। यह तेजी से संपत्ति के उपयोग के लिए दृश्यों के पीछे होता है। Google इसे the design of V8 में बताता है। अनिवार्य रूप से, यदि आपके पास एक ही कक्षा के कई छोटे उदाहरण हैं जो कम या ज्यादा स्थिर हैं (यानी, वर्ग के प्रत्येक उदाहरण में समान गुण हैं), V8 इस मामले के लिए अनुकूलित कर सकता है।

Answer 5

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

यह पैटर्न जावास्क्रिप्ट पुस्तकालयों में पूरी जगह पर है। यह इस तरह दिखता है:

var Template = { 
    extend: function() { 
    var F = function() {}; 
    F.prototype = this.prototype; 
    var instance = new F(); 
    instance.mixin.apply(instance, arguments); 

    return instance; 
    }, 

    mixin: function (mixins) { 
    for (var i = 0, len = arguments.length; i < len; i++) { 
     for (var k in arguments[i]) if (arguments[i].hasOwnProperty(k)) { 
     this[k] = arguments[i][k]; 
     } 
    } 

    return this; 
    } 
}; 

इस जादुई वर्ग विरासत जंजीरों में डेटा साझा कर देगा और आपके ऑब्जेक्ट मॉडल सरल बनाते हैं। कुछ भी कक्षा नहीं है- सब कुछ एक वस्तु है! इसका अर्थ जावास्क्रिप्ट के minutiae को समझना है, क्योंकि चिपचिपा गुओ में खुद को फंसने के लिए नहीं, लेकिन यह इसके लायक है।

इसका मतलब यह है कि आपके पास:

var Koopa = Template.extend({ 
    hasShell: true, 
    fatalFlaw: 'shell' 
}); 

var Bowser = Koopa.extend({ 
    fatalFlaw: 'tail' 
}); 

डाटा संग्रहित दिखता है इस प्रकार है:

+-------------------. +---------------------. +---------. 
| Bowser    |->| Koopa    |->| Template | 
+--------------------+ +----------------------+ +----------+ 
|fatalFlaw => 'tail' | | hasShell => true  | | mixin | 
`-------------------+ | fatalFlaw => 'shell' | | extend | 
         `---------------------+ `---------+ 

इस डिजाइन पिता Crockford के prototypal inheritance डिजाइन की वजह से उपजी। और Knuth की तरह कहते हैं: "समयपूर्व अनुकूलन सभी बुराई की जड़ है!"

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

तो, मेरा जवाब है ... लोगों को दक्षता के बारे में क्या कहना है, या सबसे अच्छा क्या है (यहां तक ​​कि मुझे!)। अपनी लाइब्रेरी के डिजाइन में, जो आपको सबसे ज्यादा समझ में आता है। अभी, आप एक गोल छेद में एक चौकोर छेद में फेंकने की कोशिश कर रहे हैं। आपको पहले यह तय करना होगा कि आपकी ज़रूरतें क्या हैं, और सब कुछ स्वाभाविक रूप से बाद में आ जाएगा। यह आपको भी आश्चर्यचकित कर सकता है!