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

அடிப்படைத் திருத்தம் சரியாகப் பெற வேண்டிய பகுதி, ஏனெனில் எவ்வளவு வரலாறு பயணிக்கும் என்பதை அது தீர்மானிக்கிறது. எல்லாவற்றையும் தொகுப்பது வேலை செய்கிறது ஆனால் இணைப்பை வீணாக்குகிறது, கடைசி பொது மாற்றத்திலிருந்து தொகுப்பது மறுபக்கத்திடம் இல்லாததை மட்டும் நகர்த்துகிறது.

அலைவரிசையைக் குறை சொல்வதற்கு முன் மூன்று செயல்பாடுகளை அளவிடுங்கள்

மூன்று விஷயங்களைத் தனித்தனியாக அளவிடுங்கள்: ஒரு சிறிய கோப்பு திறக்கப்பட்டது, ஒரு அடைவு பட்டியலிடப்பட்டது, ஒரு சேமிப்பு நிறைவடைந்தது. மூன்றும் கோப்பு எண்ணிக்கைக்கு விகிதத்தில் மெதுவாக இருந்தால், செலவு இருவழிப் பயணங்கள். ஒன்று தடைபட்டு மற்றவை நன்றாக இருந்தால், அலைவரிசை அல்ல, எட்ட முடியாத வளத்திற்கு எதிரான கால எல்லையைச் சந்தேகியுங்கள். ஒவ்வொரு ஓட்டத்திலும் இயந்திரம் எந்த வலையமைப்பில் இருந்தது என்பதைப் பதிவு செய்யுங்கள், ஏனெனில் வேறு சுயவிவரத்துடன் மீண்டும் இணையும் மடிக்கணினி முயற்சிகளுக்கு இடையே பதிலை மாற்றலாம்.

பின்னர் அதே மூன்றையும் திட்டத்தின் உள்ளூர் பிரதிக்கு எதிராக மீண்டும் செய்யுங்கள். வேறுபாடு பங்கீட்டின் விலை, மேலும் யாராவது தீர்வாக வேகமான இணைப்பைப் பரிந்துரைக்கும்போது மேற்கோள் காட்ட வேண்டிய எண் அதுவே.