VPN शेअरवर Visual Studio संथ: सेव्ह का राउंड ट्रिप होतो

स्थानिक डिस्कवरून एका सेकंदात उघडणारे समाधान टनेलमधून पोहोचणाऱ्या शेअरवरून उघडायला तीस सेकंद घेते। टनेल स्वतःच क्वचितच कारण असते। जे बदलते ते म्हणजे जे ऑपरेशन स्थानिक कॉल होते ते समकालिक राउंड ट्रिप होतात, आणि विंडो दिसण्यापूर्वी संपादक त्यापैकी अनेक करतो। खालील यंत्रणा स्पष्ट करते की प्रत्येक का महाग आहे आणि कोणते तुम्ही काढू शकता।

फाइल उघडी असताना संपादक काय करतो

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

प्रकल्प प्रणाली स्वतःचा रहदारी जोडते। समाधान लोड करताना डिरेक्टरी मोजल्या जातात, प्रकल्प फाइली वाचल्या जातात आणि SDK किंवा पॅकेज तपासले जाऊ शकतात, आणि मार्ग दूर असताना प्रत्येक तपासणी राउंड ट्रिप असते। अनेक प्रकल्प असलेले समाधान ती संख्या गुणते, म्हणून उघडण्याची वेळ फाइल आकार सुचवतील त्यापेक्षा वेगाने वाढते।

मेनू दिसण्यापूर्वी संपणाऱ्या शेल शोध

Windows IDE शी काहीही संबंध नसलेला दुसरा स्तब्धतेचा स्रोत जोडते। Explorer आणि त्याचे शेल विस्तार प्रत्येक वेळी संदर्भ मेनू उघडल्यावर यापूर्वी वापरलेले प्रिंटर, मॅप केलेले ड्राइव्ह आणि शॉर्टकट पुन्हा सोडवतात। जेव्हा ती लक्ष्ये अशा नेटवर्कवर असतात जिथे टनेल पोहोचत नाही, तेव्हा प्रत्येक सोडवणूक कालमर्यादा संपेपर्यंत अडवते, आणि मगच मेनू रेखाटला जातो। म्हणूनच फाइल स्वतः सामान्यपणे उघडत असतानाही उजवे क्लिक अनेक सेकंद लटकू शकते।

मृत मॅपिंग आणि प्रिंटर रांगा काढा, किंवा तुम्ही खरोखर ज्या नेटवर्कवर आहात तिथे असलेलीच ठेवा। तीच तर्कशास्त्र पार्श्वभूमीत मार्ग सोडवणाऱ्या प्रत्येक गोष्टीला लागू होते, त्यात अलीकडील फाइल यादी आणि पिन केलेले फोल्डर यांचा समावेश आहे।

net use
Get-Printer | Select-Object Name, PortName
Measure-Command { Get-ChildItem \files\proj | Out-Null }

स्थानिक कार्यरत प्रत का जिंकते

शेअरवर थेट काम करणे संपादन-बिल्ड-चाचणी चक्रासाठी सर्वात वाईट रचना आहे, कारण संपादक, कंपाइलर आणि आवृत्ती नियंत्रण क्लायंट प्रत्येक त्या दूरच्या फाइली स्वतंत्रपणे वाचतो। त्यांपैकी प्रत्येकजण स्वतःची राउंड ट्रिप भरतो, आणि बिल्ड प्रत्येक फाइलमागे एकदा भरते। रेपॉझिटरीमधून पुशसह स्थानिक प्रत लहान ओलांडण्यांचा पूर एका जाणीवपूर्वक ओलांडण्याने बदलते। दुवा सुधारला नाही; ओलांडण्यांची संख्या कोसळली।

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

इतिहास एकाच ऑब्जेक्ट म्हणून हलवा

जेव्हा रेपॉझिटरीलाच टनेल ओलांडावे लागते, तेव्हा इतिहास चालण्याऐवजी एकाच ऑब्जेक्टमध्ये पाठवा। बंडल एक फाइल आहे आणि म्हणून एक हस्तांतरण, तर हजारो सुटे ऑब्जेक्ट चालणारा checkout हजारो ओलांडण्यांचा खर्च करतो। Mercurial आणि Git दोन्ही ते स्वरूप समर्थतात।

hg bundle --base 9f2c1a7e outgoing.hg
hg unbundle outgoing.hg
git bundle create repo.bundle main
git clone repo.bundle repo

आधार आवृत्ती हा बरोबर मिळवायचा भाग आहे, कारण ती किती इतिहास प्रवास करेल हे ठरवते। सर्व काही बंडल करणे काम करते आणि दुवा वाया घालवते, तर शेवटच्या सामायिक बदलापासून बंडल करणे फक्त दुसऱ्या बाजूकडे जे नाही तेच हलवते।

बँडविड्थला दोष देण्यापूर्वी तीन ऑपरेशन मोजा

तीन गोष्टी वेगवेगळ्या मोजा: एक लहान फाइल उघडली, एक डिरेक्टरी सूचीबद्ध, एक सेव्ह पूर्ण। तिन्ही फाइल संख्येच्या प्रमाणात संथ असतील, तर खर्च राउंड ट्रिप आहे। एक अडकला आणि बाकीचे ठीक असतील, तर बँडविड्थ नाही तर पोहोच न शकणाऱ्या संसाधनाविरुद्ध कालमर्यादेचा संशय घ्या। प्रत्येक रनमध्ये मशीन कोणत्या नेटवर्कवर होती ते नोंदवा, कारण दुसऱ्या प्रोफाइलला पुन्हा जोडणारा लॅपटॉप प्रयत्नांमध्ये उत्तर बदलू शकतो।

मग तेच तीन प्रकल्पाच्या स्थानिक प्रतीविरुद्ध पुन्हा करा। फरक म्हणजे शेअरची किंमत, आणि कोणी उपाय म्हणून वेगवान दुवा सुचवेल तेव्हा उद्धृत करायची संख्या तीच आहे।