2011-07-07 11 views
16

मेरे पास एक बड़ा, जावास्क्रिप्ट भारी वेब ऐप है जिस पर मैं काम कर रहा हूं। मुझे एक्सएचआर प्रतिक्रियाओं और कंसोल लॉगिंग (3-5 सेकेंड) के लिए क्रोम देव टूल्स से बहुत धीमी प्रतिक्रिया समय का सामना करना पड़ रहा है। वास्तविक ऐप तेजी से और उत्तरदायी चल रहा है, केवल देव उपकरण दिखता है जैसे यह पीड़ित है।बड़े वेब ऐप में प्रतिक्रिया देने के लिए क्रोम देव उपकरण बहुत धीमे

क्या किसी को पता है कि क्रोम देव उपकरण क्यों बढ़ रहा है क्योंकि मेरा ऐप बढ़ता है?

+0

बना मैं वर्तमान में डोजो के साथ काम करते हुए इस समस्या का सामना कर रहा हूँ। अजीब चीज यह है कि यह केवल डोजो के संपीड़ित संस्करण के साथ होता है। स्रोत संस्करण के साथ काम करना ठीक काम करता है। मुझे लगता है कि समस्या दूसरी तरफ होनी चाहिए। – Marcelo

उत्तर

3

देवतोल्स किसी भी अन्य डीबगर की तरह हैं; वे एक आवेदन के सामान्य प्रसंस्करण प्रवाह में हुक करते हैं, और सामान्य रूप से आवश्यकतानुसार काफी अधिक जानकारी संग्रहीत करते हैं। डिबगिंग सक्षम किए बिना पेज को बस प्रस्तुत करने से यह अधिक काम है, इसलिए यह वास्तव में धीमा होगा।

उस ने कहा, console.log का जवाब देने के लिए 3 सेकंड अधिक लगता है। मैं सुझाव दूंगा कि आप पहले nightly version of WebKit में एप्लिकेशन का परीक्षण करें। यदि यह वेबकिट में उत्तरदायी है, लेकिन क्रोम में नहीं है, तो कृपया http://new.crbug.com/ के माध्यम से इंस्पेक्टर के खिलाफ एक बग दर्ज करें, जिसके साथ आप जो परिस्थिति प्रदान कर सकते हैं, वह किस परिदृश्य के कारण धीमा हो जाता है। , https://bugs.webkit.org/enter_bug.cgi

किसी भी तरह से यहाँ पोस्ट बग आईडी, और मैं देखेंगे कि यह सही टीम में triaged है:

यदि यह WebKit में समान रूप से सुस्त है, WebKit के इंस्पेक्टर घटक के खिलाफ एक बग फ़ाइल करें।

+1

क्रोम के डीबगर चॉकलेट पर उसी बड़े पृष्ठ को डीबग करते समय फ़ायरफ़ॉक्स/फ़ायरबग अधिक प्रतिक्रियाशील होते हैं। और मुझे क्रोम पसंद है! –

1

यह एक पुराना सवाल है, लेकिन यह बाद में मेरे जैसे लैंडिंग में मदद कर सकता है।

लिनक्स पर क्रोम 46.x/47.x का उपयोग (आरएचईएल 7), प्रस्तावित समाधानों में से कोई भी मेरे लिए काम नहीं करता है। उन्नत ब्राउज़र सेटिंग्स में "उपलब्ध होने पर हार्डवेयर त्वरण का उपयोग करें" सेटिंग को अक्षम करने के लिए काम क्या था।

मैंने प्रक्रिया मॉनीटर/सूची में देखा है कि क्रोम रेंडरर बहुत सी सीपीयू ले रहा था, यहां तक ​​कि ब्रेकपॉइंट डालने या डीबगर में कथन के माध्यम से कदम उठाने में 10+ सेकंड लगेंगे!

एक शॉट के लायक हो सकता है।

+0

कृपया लिंक को केवल अन्य स्टैक ओवरफ़्लो प्रश्नों के उत्तर पोस्ट न करें। इसके बजाय, डुप्लिकेट के रूप में बंद करने के लिए वोट/ध्वज, या, यदि प्रश्न डुप्लिकेट नहीं है, तो इस विशिष्ट प्रश्न का उत्तर तैयार करें। –

+0

ठीक है, क्या मुझे जवाब पूरी तरह से लेना चाहिए? यह वास्तव में एक डुप्लिकेट नहीं है, और यह पहले से ही दूसरे प्रश्न से जुड़ा हुआ है। – AsGoodAsItGets

+0

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

0

डेवलपर टूल को अलग विंडो में अनदेखा करें। मेरे मामले में, यह काम है।

+1

दिमाग? – manetsus

0

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

4

मैं "निर्धारित" धीमी क्रोम डेवलपर द्वारा (स्रोत टैब के अंतर्गत) उपकरण

  • समाशोधन सूची है कि समय पर जमा "घड़ी" ...
  • सभी "के टुकड़े" समाशोधन, मैं था दर्जनों के साथ-साथ ...

सुनिश्चित नहीं हैं कि दोनों के सबसे फर्क पड़ा है, लेकिन यह निश्चित रूप से एक अंतर

संबंधित मुद्दे