VPN വഴി SSHFS-ൽ git status മന്ദഗതിയിൽ: ജോലി മാറ്റുക

200 MB ഫയൽ പകർത്തൂ, അത് പറക്കും. അതേ ഡയറക്ടറിയിൽ git status പ്രവർത്തിപ്പിക്കൂ, കാത്തിരിപ്പ് മറ്റെന്തെങ്കിലും ചെയ്യാൻ തോന്നുന്നത്ര നീളമുള്ളതാണ്. ഈ രണ്ട് നിരീക്ഷണങ്ങളും വിരുദ്ധമല്ല, കാരണം ബൾക്ക് കൈമാറ്റം ത്രൂപുട്ട് അളക്കുന്നു, Git മാത്രം സെക്കൻഡിൽ എത്ര ചെറിയ ഫയൽസിസ്റ്റം ചോദ്യങ്ങൾ ചോദിക്കാം എന്ന് അളക്കുന്നു, കൂടാതെ മൗണ്ട് ചെയ്ത ദൂര ട്രീ ഓരോ ചോദ്യത്തെയും ഒരു യാത്രയാക്കി മാറ്റുന്നു. VPN ട്യൂൺ ചെയ്യുന്നത് തെറ്റായ ആകൃതിയിലുള്ള ജോലിഭാരം ശരിയാക്കില്ല.

status എന്തുകൊണ്ട് തെറ്റായ അളവുകോൽ

Git-ന് ധാരാളം ഫയലുകളെക്കുറിച്ച് അറിയണം: ഏതാണ് മാറ്റിയത്, ഏതാണ് ട്രാക്ക് ചെയ്യാത്തത്, കൂടാതെ കാഷ് ചെയ്ത ഇൻഡക്സ് ഡാറ്റ ഇപ്പോഴും ഡിസ്കിലുള്ളതുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ. SSHFS വഴി ഈ നിരീക്ഷണങ്ങളിൽ ഓരോന്നും ഒരു നെറ്റ്വർക്ക് പ്രവർത്തനമാകാം. ഇവിടെ ജോലിയുടെ യൂണിറ്റ് ഫയലുകളുടെ എണ്ണമാണ്, മെഗാബൈറ്റല്ല.

അതുകൊണ്ടാണ് ക്ലോണിനു ശേഷമുള്ള ആദ്യ status മന്ദഗതിയാകുന്നത്, ബിൽഡ് ഔട്ട്പുട്ട് നിറഞ്ഞ ട്രീയിൽ പിന്നീടുള്ളവ ഇനിയും മന്ദഗതിയാകാം. ട്രാക്ക് ചെയ്യാത്ത ഫയലുകളുടെ സ്കാനിംഗ് നിങ്ങൾക്ക് താൽപ്പര്യമില്ലാത്ത ഡയറക്ടറികളിലൂടെ നടക്കുന്നു, ഓരോ ചുവടും ലിങ്കിലൂടെയുള്ള മറ്റൊരു അഭ്യർത്ഥനയാണ്. 40 ms പാതയിൽ കുറച്ച് ആയിരം എൻട്രികളുള്ള ട്രീ കുറച്ച് ആയിരം യാത്രകളാകുന്നു. ഈ ഗണിതം സ്ഥിരീകരിക്കാൻ പാക്കറ്റ് ക്യാപ്ചർ ആവശ്യമില്ല.

ഡൗൺലോഡ് അളവുകോൽ ലിങ്ക് കൊള്ളാമെന്ന് പറയുന്നു; ആയിരം ചെറിയ വായനകൾ ഇന്ന് ഉച്ചകഴിഞ്ഞ് തീരുമോ എന്നതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല.

ജോലി ട്രീ മാറ്റുക, ട്യൂണിംഗ് നോബ് അല്ല

ലോക്കൽ ക്ലോൺ ജോലി ട്രീ, ഇൻഡക്സ്, Git പ്രവർത്തനങ്ങൾ എന്നിവ ഒരേ യന്ത്രത്തിൽ വയ്ക്കുന്നു. അപ്പോൾ pull ഒരു കാണാവുന്ന നെറ്റ്വർക്ക് ചുവടാകുന്നു, ഓരോ ഫയൽ പരിശോധനയല്ല.

ഡെവലപ്പർക്ക് ആവശ്യമായ ഉറവിടം ലോക്കലായി സൂക്ഷിക്കാനാകുമ്പോഴെല്ലാം ഇത് യോജിക്കുന്നു, മിക്കപ്പോഴും അങ്ങനെയാണ്. commit-ഉം വിന്യാസവും തമ്മിലുള്ള അതിർത്തിയും ഇത് മൂർച്ചയാക്കുന്നു, കാരണം ലോക്കൽ ഫയൽ തിരുത്തുന്നത് ഇനി ഓടുന്ന ദൂര സേവനത്തെ അബദ്ധത്തിൽ മാറ്റുന്നില്ല; മാറ്റം മറ്റെല്ലാം പോലെ push ചെയ്ത് വിന്യസിക്കണം. വില അതാണ്, കോഡ് രണ്ടിടത്ത് നിലനിൽക്കുന്നു, അതിനാൽ ഏത് പകർപ്പാണ് അധികാരമുള്ളതെന്നും സർവറിലെ അടിയന്തര അറ്റകുറ്റപ്പണി എങ്ങനെ റിപ്പോസിറ്ററിയിലേക്ക് മടങ്ങുന്നുവെന്നും തീരുമാനിക്കുക. ആ സംഭാഷണം ആരും ഓടിക്കാൻ ആഗ്രഹിക്കാത്ത status കമാൻഡിനെക്കാൾ വിലകുറഞ്ഞതാണ്.

വർക്ക്സ്പേസ് ദൂരത്ത് തന്നെ നിൽക്കണമെങ്കിൽ, അവിടെ Git ഓടിക്കുക

ചിലപ്പോൾ വർക്ക്സ്പേസ് മാറ്റാനാകില്ല: ബിൽഡിന് ആ പരിസ്ഥിതി വേണം, ഡാറ്റ വളരെ വലുതാണ്, അല്ലെങ്കിൽ നയം ഉറവിടം ഹോസ്റ്റിൽ നിർത്തുന്നു. അപ്പോൾ ഫയലുകൾക്കരികെ തന്നെ Git-ഉം ബന്ധപ്പെട്ട ഡെവലപ്പ്മെന്റ് ടൂളുകളും ഓടിക്കുക, അനുവദിക്കപ്പെട്ട ദൂര ഷെല്ലിലൂടെയോ ദൂര വികസന പരിസ്ഥിതിയിലൂടെയോ. എഡിറ്റർ ലാപ്ടോപ്പിൽ തുടരാം, അതിന്റെ ബാക്കെൻഡ് ജോലി ട്രീയുടെ അരികിൽ പ്രവർത്തിക്കുമ്പോൾ.

അപ്പോൾ ചെലവേറിയ പ്രവർത്തനങ്ങൾ ദൂര ഹോസ്റ്റിൽ ലോക്കലായി നടക്കുന്നു, നെറ്റ്വർക്ക് ആയിരക്കണക്കിന് stat വിളികൾക്കു പകരം എഡിറ്റർ ട്രാഫിക് വഹിക്കുന്നു. ഇത് ലോക്കൽ ക്ലോണിന്റെ അതേ പരിഹാരമാണ്, മൈഗ്രേഷനല്ല, വിന്യാസ തിരഞ്ഞെടുപ്പായി പറയുന്നു.

സിങ്ക് ഉടമകളുള്ള വർക്ക്ഫ്ലോ ആണ്, കാഷ് അല്ല

സിങ്ക് ചെയ്ത വർക്ക്സ്പേസിന് ആവർത്തിച്ചുള്ള ദൂര വായനകൾ കുറയ്ക്കാം, പക്ഷേ അത് സുതാര്യമായ കാഷ് അല്ല. ഓരോ മാറ്റത്തിനും ഒരു ഉടമ, സംഘർഷങ്ങൾക്ക് ഒരു നിയമം, ഇരുവശവും തങ്ങളുടേതെന്ന് കരുതുന്ന ജനറേറ്റ് ചെയ്ത ഫയലുകളെക്കുറിച്ച് ഒരു ധാരണ എന്നിവ വേണം. ആ നിയമങ്ങളില്ലാതെ ക്രമീകരണം സൗകര്യത്തിനുപകരം അഭിപ്രായവ്യത്യാസം സൃഷ്ടിക്കുന്നു.

അവയില്ലാത്ത ഇരുദിശാ സിങ്ക് ചെയ്യുന്നത് പരിഹരിച്ച പ്രശ്നത്തിൽനിന്ന് വ്യത്യസ്തമായ ഒന്ന് സൃഷ്ടിക്കുന്നു, സാധാരണയായി ആർക്കും ആരോപിക്കാനാകാത്ത ഒരു മെർജ്. ഒരു പങ്കിട്ട ജോലി ട്രീയിൽ രണ്ട് Git പ്രോസസുകൾ ഓടിക്കുന്നത് ഒഴിവാക്കുക, അവ എങ്ങനെ ഏകോപിക്കുന്നുവെന്ന് മനസ്സിലായില്ലെങ്കിൽ.

പിന്നീട് ട്യൂൺ ചെയ്യുക, SSH വിവേകത്തോടെ നിർത്തുക

ക്രമീകരണം ശരിയായാൽ, രണ്ട് ക്രമീകരണങ്ങൾ Git എത്ര ഫയലുകളെക്കുറിച്ച് ചോദിക്കണം എന്നത് മാറ്റുന്നു: status.showUntrackedFiles ഉം core.untrackedCache-ന് പിന്നിലെ ട്രാക്ക് ചെയ്യാത്ത കാഷും. രണ്ടും 40 ms-ൽ ഓരോ ചോദ്യത്തിന്റെയും ചെലവ് മാറ്റുന്നില്ല; ചോദ്യങ്ങളുടെ എണ്ണം മാത്രമാണ് മാറ്റുന്നത്. യാത്രകൾ ലോക്കലായതിനു ശേഷം മാത്രം നോബ് തിരിക്കുക.

ഒരു വലിയ ഫയൽ പകർത്തുന്ന അളവുകോലിൽനിന്ന് അനുമാനിക്കുന്നതിനുപകരം നിങ്ങളെ ശല്യപ്പെടുത്തുന്ന കമാൻഡിന്റെ സമയം അളക്കുക, പിന്തുണയുള്ള SSH എൻക്രിപ്ഷൻ അതേപടി വയ്ക്കുക. കാലഹരണപ്പെട്ട സൈഫർ യാത്ര ചുരുക്കുന്നില്ല; ആദ്യത്തേതിനെക്കാൾ കൂടുതൽ നിലനിൽക്കുന്ന രണ്ടാമത്തെ പ്രശ്നം ചേർക്കുന്നു. git status റഫറൻസ് ഒരു വായനയ്ക്ക് അർഹമാണ്, കാരണം കമാൻഡ് അതിന്റെ പേര് സൂചിപ്പിക്കുന്നതിനേക്കാൾ എത്രയോ കൂടുതൽ ജോലി ചെയ്യുന്നു.