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

आधार संशोधन ठ्याक्कै भेटाउनुपर्ने भाग हो, किनकि यसले कति इतिहास यात्रा गर्ने निर्धारण गर्छ। सबै कुरा बन्डल गर्नु काम गर्छ र लिङ्क बर्बाद गर्छ, जबकि अन्तिम साझा परिवर्तनबाट बन्डल गर्दा अर्को पक्षसँग नभएको मात्र सारिन्छ।

ब्यान्डविथलाई दोष दिनुअघि तीन अपरेसन नाप्नुहोस्

तीन कुरा अलग-अलग नाप्नुहोस्: एउटा सानो फाइल खुल्यो, एउटा डिरेक्टरी सूचीबद्ध भयो, एउटा बचत पूरा भयो। तीनै फाइल संख्याको अनुपातमा ढिलो भए, लागत राउन्ड ट्रिप हो। एउटा अड्कियो र अरू ठीक भए, ब्यान्डविथ नभई पुग्न नसकिने स्रोतविरुद्ध समयसीमाको शङ्का गर्नुहोस्। प्रत्येक रनमा मेसिन कुन नेटवर्कमा थियो नोट गर्नुहोस्, किनकि अर्को प्रोफाइलमा पुनः जोडिने ल्यापटपले प्रयासबीच उत्तर बदल्न सक्छ।

त्यसपछि तीही तीन परियोजनाको स्थानीय प्रतिविरुद्ध दोहोर्याउनुहोस्। फरक साझेदारीको मूल्य हो, र कोहीले समाधानका रूपमा छिटो लिङ्क सुझाउँदा उद्धृत गर्नुपर्ने संख्या त्यही हो।