Visual Studio ช้าบนแชร์ VPN: ทำไมการบันทึกจึงกลายเป็นการเดินทางไปกลับ

โซลูชันที่เปิดได้ในหนึ่งวินาทีจากดิสก์ในเครื่องใช้เวลาสามสิบวินาทีเมื่อเปิดจากแชร์ที่เข้าถึงผ่านอุโมงค์ ตัวอุโมงค์เองไม่ค่อยเป็นสาเหตุ สิ่งที่เปลี่ยนคือ การดำเนินการที่เคยเป็นการเรียกในเครื่องกลายเป็นการเดินทางไปกลับแบบซิงโครนัส และตัวแก้ไขทำหลายอย่างก่อนหน้าต่างจะปรากฏ กลไกด้านล่างอธิบายว่าทำไมแต่ละอย่างจึงมีต้นทุนสูงและอะไรที่คุณตัดออกได้

ตัวแก้ไขทำอะไรขณะไฟล์เปิดอยู่

ตัวแก้ไขที่มีการติดตามการเปลี่ยนแปลงจะเก็บการสมัครรับข้อมูลไว้บนทุกไฟล์ที่เปิดอยู่ ไดรฟ์ในเครื่องให้บริการการสมัครนั้นจากระบบไฟล์โดยไม่ใช้เครือข่าย ผ่านแชร์ คุณสมบัติเดียวกันอาจเสื่อมลงเป็นการอ่านเมทาดาทาซ้ำ ๆ เพราะรูปแบบการแจ้งเตือนไม่ทำงานเหมือนกันบน 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

รีวิชันฐานคือส่วนที่ต้องทำให้ถูก เพราะมันกำหนดว่าจะเดินทางประวัติมากน้อยแค่ไหน การรวมทุกอย่างได้ผลแต่สิ้นเปลืองลิงก์ ขณะที่การรวมจากการเปลี่ยนแปลงร่วมครั้งล่าสุดจะย้ายเฉพาะสิ่งที่อีกฝั่งขาด

วัดสามการดำเนินการก่อนจะโทษแบนด์วิดท์

วัดสามอย่างแยกกัน ไฟล์เล็กหนึ่งไฟล์เปิด ไดเรกทอรีหนึ่งรายการถูกแสดง การบันทึกหนึ่งครั้งเสร็จสิ้น หากทั้งสามช้าตามสัดส่วนจำนวนไฟล์ ต้นทุนคือการเดินทางไปกลับ หากอย่างหนึ่งติดขัดในขณะที่อื่น ๆ ปกติดี ให้สงสัยการหมดเวลากับทรัพยากรที่เข้าถึงไม่ได้ ไม่ใช่แบนด์วิดท์ บันทึกว่าเครื่องอยู่บนเครือข่ายใดในการรันแต่ละครั้ง เพราะแล็ปท็อปที่เชื่อมต่อโปรไฟล์อื่นใหม่สามารถเปลี่ยนคำตอบระหว่างความพยายาม

จากนั้นทำสามอย่างเดิมซ้ำกับสำเนาในเครื่องของโปรเจกต์ ความแตกต่างคือราคาของแชร์ และนั่นคือตัวเลขที่ควรอ้างอิงเมื่อมีคนเสนอให้ใช้ลิงก์ที่เร็วกว่าเป็นทางแก้