2011-08-30 10 views
9

काम पर हम कुछ सुंदर शक्तिशाली मशीनों का उपयोग कर रहे हैं: एचपी जेड 600 दोहरी xeon @ 2.5GHz, 8-16GB रैम के साथ। दुर्भाग्य से बीमार फिटिंग कंपनी नीतियों के कारण हमें 32-बिट एक्सपी का उपयोग करने के लिए मजबूर होना पड़ता है, इसलिए मैंने अप्रयुक्त 4 जीबी रैम से पीएई रैमड्राइव बनाया।
अब, अस्थायी फ़ाइलें रैमड्राइव पर हैं। मैंने पूरे प्रोजेक्ट को रैमड्राइव में ले जाने की कोशिश की है, फिर एक एसएसडी में, लेकिन होस्टेड-मोड स्टार्टअप या संकलन समय में कोई उल्लेखनीय सुधार नहीं हुआ है।
मैंने फिर SysInternals 'प्रोसेस मॉनिटर को यह देखने के लिए चलाया है कि क्या कोई बाधाएं हैं जो कार्य प्रबंधक/हार्ड-डिस्क गतिविधि के साथ दिखाई नहीं दे रही हैं, लेकिन मैंने कुछ भी उल्लेखनीय नहीं देखा है - कुछ बफर ओवरफ्लो को छोड़कर जिन्हें मैं समझ नहीं पा रहा हूं उनका क्या मतलब है।

मैं मान सकता हूं कि ओओएमपीएच स्टार्टअप और जीडब्ल्यूटी संकलन के लिए प्रदर्शन बंधे हैं इसलिए मैं विभिन्न परिवर्तनों के बीच बेंचमार्किंग के रूप में संकलन के समय का उपयोग कर रहा हूं।
मैंने BIOS में हाइपर-थ्रेडिंग और टर्बो-बूस्ट को सक्रिय और निष्क्रिय कर दिया है, लेकिन फिर से कोई अंतर नहीं देखा। हाइपरथ्रेडिंग भी सबकुछ धीमा कर देती है, मैं मान सकता हूं कि 8 कोर के मुकाबले 16 कोर के लिए संदर्भ स्विचिंग जुर्माना अधिक है। टर्बो-बूस्ट कुछ भी नहीं प्रतीत होता है, मुझे लगता है कि यह केवल Win7 के तहत काम करता है, मैं ड्राइवर को सक्रिय करने में सफल नहीं हुआ हूं। इसे कोर को 2.5 गीगा से 2.8 गीगा तक बढ़ा देना चाहिए।
एनटीएफएस ड्राइव पर निष्क्रिय इंडेक्सिंग और टाइमस्टैम्पिंग, अग्रभूमि से पृष्ठभूमि और पीछे प्रदर्शन सेटिंग बदल दी, ग्रहण के दूसरे उदाहरण का उपयोग किया - कोई बदलाव नहीं।
संकलन के लिए मैंने श्रमिकों, बड़ी मेमोरी और कुछ अन्य विकल्पों को निर्दिष्ट करने की कोशिश की है। दो श्रमिकों के ऊपर सबकुछ संकलन समय बढ़ाता है।
पुरानी एचपी मशीनें (एक्सडब्ल्यू 6600) शायद 2.8GHz घड़ी की वजह से थोड़ी तेज़ी से संकलित लगती हैं, लेकिन उनके होस्ट किए गए मोड धीमे होने लगते हैं।
जीडब्ल्यूटी होस्टेड मोड/संकलन के समय में सुधार कैसे करें?

सारांश में, स्मृति उपयोग के बारे में 2.6GB पर है, पृष्ठ फ़ाइल उपयोग शून्य है, हार्डड्राइव ज्यादा गतिविधि का संकेत नहीं है, सीपीयू गतिविधि < 10% (50-70 के बारे में% पर सिंगल कोर), लेकिन अभी भी कंप्यूटर है ओओएमपीएच जीडब्ल्यूटी को संकलित या लॉन्च करते समय कुछ समय के लिए कुछ भी नहीं लगता है।
ठीक है, तो अब मैंने इंटरनेट पर जो कुछ भी मुझे पाया और पाया, कोशिश की है, क्या कोई और चीज है जिसे मैं कोशिश कर सकता हूं? 64-बिट Win7 पर स्विच करने से काफी सुधार होगा (यह वैसे भी अगले वर्ष है)? क्या कोई हार्डवेयर/सॉफ़्टवेयर विकल्प हैं जो मैं ट्विक कर सकता हूं?

एल.ई .: भी आरएटीटी (एमएस से ट्रेसर) चला गया ताकि यह देखने के लिए कि क्या कोई इंटरप्ट बहुत लंबा समय ले रहा है, लेकिन सबकुछ क्रम में लगता है। एंटीवायरस कोई फर्क नहीं पड़ता है। मेरे आई 7 मोबाइल (2630 वर्ग) के खिलाफ एक और जीडब्ल्यूटी परियोजना बेंचमार्क किया गया और आई 7 लगभग 70% तेज है, हालांकि इसमें लगभग एक ही घड़ी है।

+0

+ 1 मुझे इसमें भी रूचि है। मेरे अवलोकनों से यह सीपीयू बाध्य है (भले ही इसे सीपीयू 100% तक नहीं मिलता है) - कोर 2 डुओ 2GHz से कोर I3 2.6Ghz पर जाकर होस्टेड मोड में स्टार्ट अप टाइम लगभग आधा हो गया। (~ 60 से ~ 30 तक) –

उत्तर

8

ज्यादातर मामलों में मुझे धीमी संकलन/होस्टेड मोड रीफ्रेश का कारण सामने आया है कि एप्लिकेशन इस तरह लिखा गया है।

  • अपने classpath में अप्रयुक्त वर्गों और मॉड्यूल रखने के लिए, क्योंकि GWT उन्हें precompile चरण
  • whatch पर वैसे भी पार्स करने है यदि संभव हो तो उन्हें न निकालें:

    संकलन के लिए वहाँ कुछ चीजें के लिए बाहर देखने के लिए कर रहे हैं GWT-RPC प्रकार विस्फोट के लिए बाहर, यह आम तौर पर सभी समस्याओं का एक कारण है

  • वास्तव में इंटरफ़ेस ContextWithLokup साथ सावधान रहो, हमेशा कुछ बाहर की जाँच करने के लिए इंटरफ़ेस में इस्तेमाल किया तरीकों की संख्या जो ContextWithLookup फैली
  • कोशिश कम करने की कोशिश अन्य संकलन विकल्प, distributed compilation, soft permutations या बहु JVM संकलन की तरह (सिस्टम संपत्ति के साथ संकलक चलाने -Dgwt.jjs.permutationWorkerFactory = com.google.gwt.dev.ExternalPermutationWorkerFactory और -localWorkers JVMs की संख्या निर्दिष्ट करने)

द्वारा होस्ट किए गए के लिए:

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

यही सब मैं सलाह दे सकता हूं। रैम डिस्क की तरह सामान सामान की गति को बढ़ा सकता है, क्योंकि यह बड़ी संख्या में फाइलें उत्पन्न कर सकता है।

+0

अप्रयुक्त वर्गों के बारे में अच्छी युक्ति, मैं इसके बारे में भूल गया (और हमने वैसे भी precompiler ओवरराइड किया है)। बस 'प्रकार विस्फोट' के बारे में पता चला लेकिन हमने हमेशा स्पष्ट रूप से परिभाषित क्रमबद्ध प्रकारों को परिभाषित किया है। हम आम तौर पर केवल एक क्रमपरिवर्तन संकलित करते हैं और मेरी शिकायत केवल एक (या बल्कि प्रीकंपिलेशन चरण) को संकलित करने के बारे में है, इसलिए वितरित संकलन बहुत मदद नहीं करेगा। स्थानीय कार्यकर्ता लगभग कोई फर्क नहीं पड़ता है। आलसी लोडिंग जितना संभव हो सके लेकिन इस बिंदु से इसे पुन: आर्किटेक्चरिंग की आवश्यकता होती है क्योंकि इसे शुरुआत से बुरी तरह से डिजाइन किया गया था। एक बार फिर, अप्रयुक्त मॉड्यूल एक बहुत अच्छी टिप है! – brainwash