xcode - एक्सकोड 4-धीमी प्रदर्शन




performance xcode4 (12)

एक्सकोड 4.2, 4.3:

फ़ाइल-इंडेक्सर के साथ प्रमुख समस्याएं (एक ही कोड जो स्पॉटलाइट चलाता है, जो वर्षों से छोटी है? शायद)।

"देखने" फ़ाइलों के साथ शामिल सभी आवश्यक गैर-आवश्यक अक्षम करें:

  1. त्वरित सहायता (एनबी: क्यूएच टैब पर कभी भी क्लिक न करें! सहायक को छुपाएं अभी भी कोड को चलाने का कारण बनता है! एक नई फाइल पर जाने से पहले एक अलग टैब पर स्विच करें ...)
  2. एससीएम प्रबंधन (एसवीएन, गिट, इत्यादि - एक्सकोड का गिट समर्थन अभी भी एक छोटी छोटी गाड़ी है (भ्रष्ट परियोजनाएं कर सकता है), और उन्होंने एसवीएन समर्थन को छोड़ दिया है, इसलिए आपको इसका उपयोग नहीं करना चाहिए!)
  3. अपने वर्कस्पेस फ़ोल्डर को हटाने का प्रयास करें (स्वीकृत उत्तर के अनुसार), लेकिन केवल डिस्क पर इसकी बड़ी है
  4. ... व्यक्तिगत फाइलों की स्थिति से संबंधित कुछ भी आप पा सकते हैं

एक्सकोड 4.4, 4.5:

इन संस्करणों में एक प्रमुख मेम रिसाव है, एक टूटी हुई फाइल इंडेक्सर (लेकिन 4.2 और 4.3 से बेहतर), और शायद एक निजी स्वैप फ़ाइल समस्या हो सकती है।

आखिरकार, स्वैप स्पेस को अक्षम / सक्षम करने ( मैक ओएस एक्स में स्वैपिंग को अक्षम या सक्षम करने के लिए ), और कई मशीनों पर सामान्य हार्ड ड्राइव का उपयोग करके और 16 जीबी रैम तक 2 जीबी रैम वाली मशीनों पर प्रयोग चलाकर, मैंने पाया कि एक्सकोड ओएस एक्स स्वैप (!) से स्वतंत्र, अपने स्वयं के स्वैप-स्पेस को चलाने लगता है।

(यह एक गलती हो सकती है - शायद ओएस एक्स स्वैपिंग का एक अतिरिक्त रूप है जिसके बारे में मुझे पता नहीं है - लेकिन सिस्टम स्वैप फाइलें बड़ी या छोटी नहीं होतीं, जबकि डिस्क स्पेस कुछ मशीनों पर गीगाबाइट्स ऊपर और नीचे कूदती है)

देखे गए:

  1. एक्सकोड 4.4 / 4.5 यादृच्छिक रूप से आपके सिस्टम में सभी रैम (एक छोटी परियोजना के लिए जीबी का 10) ले जाएगा ताकि शेष सिस्टम एक रोक लगाए, डिस्क स्वैपिंग के लिए प्रतीक्षा कर रहा हो

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

  3. एक्सकोड को ओएस एक्स स्वैप स्पेस की आवश्यकता नहीं है

आखिरी एक बहुत दिलचस्प है। यदि आपके पास बहुत मेमोरी है (उदाहरण के लिए 16 जीबी), स्वैप स्पेस को स्थायी रूप से अक्षम करने का प्रयास करें। एक्सकोड तेजी से चलता है, क्योंकि ओएस एक्स शेर में मेम प्रबंधन में कुछ बग हैं जहां इसे आवश्यकता होने पर भी इसे बदल जाता है

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

(यदि आपके पास एसएसडी है, तो एकमात्र तरीका यह जान सकता है कि क्या यह शुरू हो रहा है या नहीं, "धीमे हो जाएं" के लिए प्रतीक्षा करना है। अन्यथा, जैसे ही आप एचडी थ्रैश सुनते हैं, आप जानते हैं: अब कोई सिस्टम स्वैपफाइल नहीं है, इसलिए एक्सकोड केवल संभावित कारण है)

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

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

मुझे एक्सकोड 4 के साथ वास्तव में उपयोगकर्ता इंटरैक्शन के लिए बहुत धीरे-धीरे प्रतिक्रिया दे रहा है, उदाहरण के लिए संपादन कोड, स्क्रॉलिंग इत्यादि। यह विशेष रूप से बड़े नियंत्रकों के साथ होता है जिसमें कई नियंत्रक / फाइलें इत्यादि होती हैं।

मैंने पूरी तरह से हार्ड डिस्क को मिटा दिया और दूसरे सप्ताह में हिम तेंदुए और एक्सकोड को फिर से स्थापित किया लेकिन धीरे-धीरे यह एक निराशाजनक प्रतिक्रिया समय पर (कई दिनों में) वर्कफ़्लो को बाधित कर रहा है।

मैंने अवसर पर ऑर्गनाइज़र -> प्रोजेक्ट्स के माध्यम से प्रोजेक्ट के "व्युत्पन्न डेटा" को भी हटा दिया है और इसका बहुत कम प्रभाव पड़ा है।

मैं सोच रहा हूं कि पहले उदाहरण में उच्च स्क्वाड मशीन प्राप्त करने के अलावा प्रदर्शन में सुधार करने के लिए मैं कुछ भी कर सकता हूं।

एफवाईआई मैं इंटेल कोर 2 डुओ प्रोसेसर के साथ 2GHz और 4 जीबी रैम पर मैकबुक चला रहा हूं।

यदि हमें अपग्रेड करने की आवश्यकता है तो मैं यह भी जानना चाहूंगा कि लोग अच्छी तरह से specced मशीनों पर एक्सकोड 4 से इस खराब प्रदर्शन का अनुभव कर रहे हैं (जो हमारे हार्डवेयर अपग्रेड को व्यर्थ बना देगा क्योंकि यह केवल एक्सकोड है जिसमें मैकबुक पर कोई प्रदर्शन समस्या है)।

अगर किसी के पास कोई सुझाव या सिफारिशें हैं या हमें यह भी बता सकते हैं कि बड़े प्रोजेक्ट पेड़ों पर एक्सकोड के प्रदर्शन को बेहतर तरीके से कैसे प्रभावित किया जाए तो यह बेहद सहायक और अन्य देवताओं के लिए एक समान स्थिति में एक मूल्यवान संसाधन भी होगा।



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

$ defaults write com.apple.dt.XCode IDEIndexDisable 1

इन मामलों में से कोई भी वास्तव में मेरे मामले में प्रदर्शन में सुधार नहीं हुआ (समय के साथ एक्सकोड 4.1 शायद ही प्रयोग योग्य हो गया, केवल इसे छोड़कर और फिर मदद मिली)।

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


महत्वपूर्ण अद्यतन: एक्सकोड 6 के लिए पथ बदल गए (टिप्पणी डीसीसी के लिए धन्यवाद)! मैंने अभी वैकल्पिक तरीका जोड़ा है।

कोड की निम्न पंक्ति के साथ रैम डिस्क बनाकर बिल्ड को तेज करने के लिए एक और अच्छी चाल है:

diskutil erasevolume HFS+ "ramdisk" `hdiutil attach -nomount ram://8475854`

यह लगभग 4 जीबी के आकार के साथ एक मेमोरी डिस्क छवि बनाता है। लेकिन सावधान रहें, आपको पर्याप्त स्मृति की आवश्यकता है। बेशक आप 2 जीबी की तरह एक छोटी छवि बना सकते हैं (वह 4237 9 27 होगा)।

फिर आप एक्सकोड को वहां व्युत्पन्न डेटा स्टोर करने के लिए कहते हैं

आप एक्सकोड सिम्युलेटर डेटा को सीधे स्टोर करने के लिए एक्सकोड नहीं बता सकते हैं, लेकिन आप रैमडिस्क पर एक फ़ोल्डर बना सकते हैं और इसे करने के द्वारा आईफोन सिम्युलेटर निर्देशिका के बजाय एक प्रतीकात्मक लिंक बना सकते हैं:

एक्सकोड 6:

cd /Volumes/ramdisk
mkdir CoreSimulator
rm -R ~/Library/Developer/CoreSimulator
ln -s /Volumes/ramdisk/CoreSimulator ~/Library/Developer/CoreSimulator

पुराने एक्सकोड संस्करण:

cd /Volumes/ramdisk
mkdir iPhone\ Simulator
rm -R ~/Library/Application\ Support/iPhone\ Simulator
ln -s /Volumes/ramdisk/iPhone\ Simulator ~/Library/Application\ Support/iPhone\ Simulator

अगर मैं इस सेटअप के साथ सिम्युलेटर के लिए निर्माण करता हूं, तो यह किसी भी समय चालू और चल रहा है :)

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

अद्यतन 2013-03-12:

  1. नीचे फ्रांसिस्को गार्सिया से टिप्पणी पढ़ें!

  2. मेरे नए एमबीपी (एक एसएसडी ड्राइव युक्त) के साथ मुझे अब इस विधि की आवश्यकता नहीं है। एक्सकोड नरक की तरह चलता है :)। मुझे उम्मीद है कि यह बड़ी फलों की चिंता के लिए विज्ञापन के रूप में नहीं देखा जाता है, यह सिर्फ एक अनुभव रिपोर्ट है ...


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

  1. आंतरिक बिल्डर का उपयोग न करें, इसके बजाय बाहरी एप्लिकेशन लॉन्च करें
  2. समय-समय पर एक्सकोड छोड़ें, इससे ली गई मेमोरी को मुक्त करना चाहिए

क्षमा करें, लेकिन मुझे लगता है कि कोई बेहतर समाधान नहीं है ....: /


मुझे नहीं पता कि यह किसी की मदद करता है, लेकिन मेरे लिए, एक्सकोड को 32-बिट मोड में चलाने के लिए इसे सेट करने के बाद एक बड़ी प्रदर्शन वृद्धि हुई (यह डिफ़ॉल्ट रूप से 64 थी)। यह पुराना एक्सकोड 3 जितना तेज़ है। आप ऐप पर राइट क्लिक करके 32 बिट पर स्विच कर सकते हैं (/ डेवलपर / एप्प्लिकेशंस / एक्सकोड.एप में ) और 32-बिट मोड में जानकारी प्राप्त करना और खोलना चुनना।


मेरे मामले में यह राम उपयोग था।

कुछ क्रोम टैब, या शायद ही कभी इस्तेमाल किए गए ऐप्स को मारने का प्रयास करें। यह मदद करनी चाहिए!


यदि आप वर्कस्पेस फ़ाइल को शुद्ध करते हैं तो यह इसे गति में मदद करता है।

सबसे पहले, सुनिश्चित करें कि एक्सकोड खुला नहीं है। अब अपनी प्रोजेक्ट फ़ाइल ढूंढें। उस पर राइट-क्लिक करें, और Show Package Contents चुनें।

अगला, project.xcworkspace हटाएं।

एक्सकोड खोलें और तेज प्रदर्शन का आनंद लें!

धन्यवाद: http://meachware.blogspot.com/2011/06/speed-up-xcode-4.html

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


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


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


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





xcode4