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

પાયાની આવૃત્તિ એ સાચી રીતે મેળવવાનો ભાગ છે, કારણ કે તે નક્કી કરે છે કેટલો ઇતિહાસ મુસાફરી કરશે. બધું બંડલ કરવું કામ કરે છે અને લિંક બરબાદ કરે છે, જ્યારે છેલ્લા સામાન્ય ફેરફારથી બંડલ કરવું ફક્ત તે જ ખસેડે છે જે બીજી બાજુ પાસે નથી.

બેન્ડવિડ્થને દોષ આપતા પહેલાં ત્રણ ક્રિયાઓ માપો

ત્રણ વસ્તુઓ અલગથી માપો: એક નાની ફાઇલ ખુલી, એક ડિરેક્ટરી સૂચિબદ્ધ, એક સાચવવું પૂર્ણ. જો ત્રણેય ફાઇલ સંખ્યાના પ્રમાણમાં ધીમા હોય, તો ખર્ચ રાઉન્ડ ટ્રિપ છે. જો એક અટકે અને બાકીના ઠીક હોય, તો બેન્ડવિડ્થ નહીં પણ પહોંચી ન શકાય તેવા સ્રોત સામે સમયમર્યાદાની શંકા કરો. દરેક રનમાં મશીન કયા નેટવર્ક પર હતું તે નોંધો, કારણ કે બીજી પ્રોફાઇલ સાથે ફરી જોડાતું લેપટોપ પ્રયત્નો વચ્ચે જવાબ બદલી શકે છે.

પછી પ્રોજેક્ટની સ્થાનિક નકલ સામે એ જ ત્રણનું પુનરાવર્તન કરો. તફાવત શેરની કિંમત છે, અને જ્યારે કોઈ ઉકેલ તરીકે ઝડપી લિંક સૂચવે ત્યારે ટાંકવાની સંખ્યા એ જ છે.