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

بنیادی نظرثانی وہ حصہ ہے جو درست طور پر ملنا چاہیے، کیونکہ یہ طے کرتی ہے کہ کتنی تاریخ سفر کرے گی۔ سب کچھ بنڈل کرنا کام کرتا ہے اور لنک ضائع کرتا ہے، جبکہ آخری مشترک تبدیلی سے بنڈل کرنا صرف وہی منتقل کرتا ہے جو دوسرے فریق کے پاس نہیں۔

بینڈوڈتھ کو مورد الزام ٹھہرانے سے پہلے تین کارروائیاں ناپیں

تین چیزیں الگ الگ ناپیں: ایک چھوٹی فائل کھلی، ایک ڈائریکٹری فہرست شدہ، ایک محفوظ کرنا مکمل۔ اگر تینوں فائل تعداد کے تناسب سے سست ہوں، تو خرچ رفت و آمد ہے۔ اگر ایک رک جائے اور باقی ٹھیک ہوں، تو بینڈوڈتھ نہیں بلکہ ناقابل رسائی وسیلے کے خلاف وقت کی حد کا شبہ کریں۔ ہر رن میں مشین کس نیٹ ورک پر تھی یہ نوٹ کریں، کیونکہ دوسرے پروفائل سے دوبارہ جڑنے والا لیپ ٹاپ کوششوں کے درمیان جواب بدل سکتا ہے۔

پھر وہی تین پروجیکٹ کی مقامی نقل کے خلاف دہرائیں۔ فرق شیئرنگ کی قیمت ہے، اور جب کوئی حل کے طور پر تیز تر لنک تجویز کرے تو یہی تعداد بتانی چاہیے۔