เมื่อคุณเริ่มใช้ Windows Subsystem สำหรับ Linux เป็นครั้งแรก ทุกอย่างดูเหมือนจะทำงานได้ คุณสามารถโคลนพื้นที่เก็บข้อมูล ติดตั้งการขึ้นต่อกัน เรียกใช้แอปของคุณ และแม้แต่โน้มน้าวตัวเองว่าตอนนี้คุณมี “Linux บน Windows” แล้วมีบางอย่างผิดปกติ และคุณสังเกตเห็นว่าคำสั่งที่ควรใช้งานได้ทันทีนั้นใช้เวลานานพอสมควร การลากการติดตั้งแพ็คเกจ ผู้เฝ้าดูไฟล์มีพฤติกรรมแปลก ๆ และเซิร์ฟเวอร์การพัฒนารู้สึกเชื่องช้าในลักษณะที่ยากที่จะระบุสาเหตุเดียว ในตอนแรก สิ่งนี้ถูกตำหนิใน WSL2 เองว่าเป็นผู้กระทำผิดที่ชัดเจน แต่โดยปกติแล้วมักจะเป็นคนผิดเช่นกัน
ปัญหาที่แท้จริงคือไฟล์ของคุณอยู่ที่ไหน
ระบบไฟล์ Windows แนะนำการลงโทษประสิทธิภาพที่ซ่อนอยู่
หากโครงการของคุณตั้งอยู่ที่ใดที่หนึ่งเช่น:
/mnt/c/Users/YourName/projects/my-app
คุณไม่ได้ทำงานบนระบบไฟล์ Linux จริงๆ คุณกำลังทำงานกับระบบไฟล์ Windows ซึ่งเข้าถึงได้ผ่านเลเยอร์การแปล
รายละเอียดนั้นพลาดได้ง่ายและมีราคาแพงอย่างน่าประหลาดใจ WSL2 รันเคอร์เนล Linux จริงภายในเครื่องเสมือนน้ำหนักเบา ภายในสภาพแวดล้อมนั้น มีระบบไฟล์ Linux ดั้งเดิม มันรวดเร็ว สม่ำเสมอ และทำงานตรงตามที่เครื่องมือ Linux คาดหวัง
อย่างไรก็ตาม เมื่อคุณเข้าถึงไฟล์ภายใต้/mnt/c ,/mnt/d หรือไดรฟ์ Windows ที่ติดตั้งไว้ การดำเนินการทุกไฟล์จะต้องข้ามขอบเขตระหว่าง Linux และ Windows ขอบเขตดังกล่าวทำให้ประสิทธิภาพลดลง (อย่างเงียบๆ โดยไม่มีข้อผิดพลาด ซึ่งทำให้แย่ลง)
ที่เกี่ยวข้อง
WSL ดี แต่ยังไม่เพียงพอสำหรับฉันที่จะกลับไปใช้ Windows
ต้องใช้เวลามากกว่าเครื่อง Linux เสมือนในการทำให้ฉันอดทนกับ Copilot
ทำไมสิ่งนี้ถึงทำให้สิ่งต่าง ๆ ช้าลงจริงๆ
เวิร์กโฟลว์ไฟล์จำนวนมากขยายค่าใช้จ่ายในการแปลระบบไฟล์
ขั้นตอนการพัฒนาสมัยใหม่มีไฟล์หนักมาก ลองนึกถึงสิ่งที่เกิดขึ้นเมื่อคุณเรียกใช้บางอย่างเช่น:
npm installpip installcargo buildnpm run dev
เครื่องมือเหล่านี้สร้าง อ่าน และแก้ไขไฟล์ขนาดเล็กหลายพันไฟล์ พวกเขาอาศัยการเข้าถึงระบบไฟล์ที่รวดเร็วและพฤติกรรมที่คาดเดาได้
บนระบบไฟล์ Linux ดั้งเดิม สิ่งนี้ได้รับการปรับให้เหมาะสม แต่ในระบบไฟล์ Windows ที่เข้าถึงผ่าน WSL2 การดำเนินการแต่ละรายการเกี่ยวข้องกับการแปลระหว่างสองระบบที่แตกต่างกัน
เป็นผลให้สิ่งต่าง ๆ ทำงานได้ แต่ทุกอย่างช้าลงเท่านั้น บางครั้งก็ช้าลง 2 เท่า บางครั้งก็ช้าลง 10 เท่า และในบางกรณี มันอาจจะแย่ลงก็ได้ คุณไม่ได้สังเกตเห็นทันทีเสมอไปเนื่องจากการชะลอตัวจะกระจายไปยังการดำเนินการเล็กๆ จำนวนมาก แต่เมื่อเวลาผ่านไป มันก็เพิ่มมากขึ้น
วิธีที่ง่ายที่สุดวิธีหนึ่งในการสังเกตปัญหานี้คือการใช้ Git เรียกใช้สถานะ git หรือการชำระเงิน git บนพื้นที่เก็บข้อมูลขนาดใหญ่ที่เก็บไว้ภายใต้/mnt/c และเปรียบเทียบกับพื้นที่เก็บข้อมูลเดียวกันภายในโฮมไดเร็กทอรี Linux ของคุณ
ที่เกี่ยวข้อง
5 ฟีเจอร์ Git ที่ให้ความรู้สึกเหมือนโกงจริงๆ
มุมที่ซ่อนอยู่ของ Git เหล่านี้จะช่วยคุณประหยัดเวลาและทำให้ขั้นตอนการทำงานของคุณเจ็บปวดน้อยลง
ความแตกต่างนั้นไม่ใช่เรื่องละเอียดอ่อน เนื่องจาก Git ดำเนินการกับระบบไฟล์จำนวนมาก โดยจะสแกนไดเร็กทอรี ตรวจสอบข้อมูลเมตา และเปรียบเทียบสถานะของไฟล์ บนบริดจ์ระบบไฟล์ที่ช้า สิ่งนี้จะเห็นได้ชัดอย่างเจ็บปวด ผู้คนมักตำหนิ Git เองหรือคิดว่าพื้นที่เก็บข้อมูลของพวกเขา “ใหญ่มาก” ในความเป็นจริง ตัวเลือกระบบไฟล์กำลังสร้างความเสียหายส่วนใหญ่
อาการที่พบบ่อยอีกประการหนึ่งคือการรับชมไฟล์ที่ไม่น่าเชื่อถือ เครื่องมือเช่น webpack, Vite หรือ nodemon ขึ้นอยู่กับเหตุการณ์ของระบบไฟล์เพื่อตรวจจับการเปลี่ยนแปลง บนระบบไฟล์ Linux ดั้งเดิม เหตุการณ์เหล่านี้จะถูกส่งอย่างมีประสิทธิภาพ
ข้ามขอบเขตของ Windows สิ่งต่างๆ จะไม่สอดคล้องกัน
คุณอาจเห็น:
- การเปลี่ยนแปลงที่ไม่ก่อให้เกิดการสร้างใหม่
- โหลดซ้ำล่าช้า
- เพิ่มการใช้งาน CPU จากทางเลือกสำรอง
นี่ไม่ใช่จุดบกพร่องในเครื่องมือของคุณ แต่เป็นผลจากวิธีการแปลการแจ้งเตือนของระบบไฟล์ระหว่าง Windows และ Linux ย้ายโปรเจ็กต์ไปยังระบบไฟล์ของ WSL2 และปัญหาเหล่านี้มีแนวโน้มที่จะหายไป
การโอเวอร์คล็อกที่สำคัญ Pro DDR5 RAM 32GB (2x16GB) 6000MHz CL36
ยี่ห้อ
สำคัญ
เทคโนโลยี
DDR5
ความสะดวกที่ทำให้เข้าใจผิดของ/mnt/c
ความสะดวกสบายซ่อนค่าใช้จ่ายในการเข้าถึงข้ามระบบ
เป็นที่เข้าใจได้ว่าทำไมผู้คนถึงมาอยู่ที่นี่ คุณเริ่มต้นใน Windows และไฟล์และโปรแกรมแก้ไขของคุณอยู่ที่นั่น ให้ความรู้สึกเป็นธรรมชาติที่จะเข้าถึงได้จาก WSL2 ผ่าน/mnt/c
สิ่งนี้จะทำให้คุณเห็นภาพลวงตาของสภาพแวดล้อมที่เป็นหนึ่งเดียว ระบบไฟล์เดียว สามารถเข้าถึงได้จากทั้ง Windows และ Linux ยกเว้นว่าไม่ได้รวมเป็นหนึ่งแต่เป็นบริดจ์ และบริดจ์มีค่าใช้จ่าย
การตั้งค่านี้ใช้ได้สำหรับการเข้าถึงไฟล์เป็นครั้งคราว แต่ไม่เหมาะสำหรับปริมาณงานการพัฒนาที่ใช้งานอยู่ซึ่งขึ้นอยู่กับการทำงานของระบบไฟล์ความถี่สูง
เมื่อคุณทำงานบนระบบไฟล์ Linux ภายใน WSL2 ความแตกต่างจะเกิดขึ้นทันที เส้นทางของคุณมีลักษณะดังนี้:
ตอนนี้คุณดำเนินการทั้งหมดภายในสภาพแวดล้อม Linux และไม่มีเลเยอร์การแปลหรือค่าใช้จ่ายข้ามระบบปฏิบัติการ ภายในไดเร็กทอรีนี้ หากคุณลองติดตั้งแบบพึ่งพา คุณจะสังเกตเห็นว่าการติดตั้งเสร็จสมบูรณ์เร็วขึ้น และเซิร์ฟเวอร์การพัฒนาก็เริ่มเร็วขึ้นและโหลดซ้ำได้อย่างน่าเชื่อถือ
แต่แล้วการเข้าถึงจาก Windows ล่ะ?
ตัวแก้ไขสมัยใหม่รองรับเวิร์กโฟลว์ Linux ระยะไกลแล้ว
นี่คือส่วนที่ทำให้คนลังเล หากโปรเจ็กต์ของคุณอยู่ใน WSL2 คุณจะเปิดโปรเจ็กต์ในตัวแก้ไข Windows ได้อย่างไร
คำตอบก็คือเครื่องมือสมัยใหม่ได้แก้ไขปัญหานี้ไปแล้ว หากคุณใช้ VS Code ส่วนขยาย Remote WSL จะช่วยให้คุณสามารถเปิดระบบไฟล์ Linux ได้โดยตรง โปรแกรมแก้ไขของคุณทำงานบน Windows แต่ไฟล์จะยังคงอยู่ใน WSL2
นี่คือขั้นตอนการทำงานที่ตั้งใจไว้ มันค่อนข้างหลีกเลี่ยง (ไม่สมบูรณ์) การลงโทษด้านประสิทธิภาพในขณะที่ยังคงรักษาประสบการณ์การพัฒนาของคุณไว้ คุณยังสามารถเข้าถึงไฟล์ WSL ผ่านเส้นทางพิเศษ:
\\wsl$\YourDistro\home\youruser\projects
แต่สำหรับการพัฒนาเชิงรุก วิธีการบูรณาการระยะไกลนั้นสะอาดกว่า
เมื่อใดที่คุณยังคงใช้/mnt/c
ปริมาณงานบางส่วนยังคงได้รับประโยชน์จากระบบไฟล์ Windows
พูดตามตรง ระบบไฟล์ Windows ไม่ได้ไร้ประโยชน์ในบริบทนี้ มีกรณีการใช้งานที่ถูกต้อง เช่น การเข้าถึงเอกสารหรือไฟล์สื่อ การแชร์สคริปต์ง่ายๆ ระหว่างสภาพแวดล้อม และการทำงานร่วมกันกับเครื่องมือที่ใช้ Windows เท่านั้น แต่สำหรับการพัฒนาที่ใช้งานอยู่ โดยเฉพาะอย่างยิ่งสิ่งใดก็ตามที่เกี่ยวข้องกับโครงสร้างการพึ่งพาขนาดใหญ่หรือการดำเนินการกับไฟล์บ่อยครั้ง ถือเป็นตำแหน่งที่ไม่ถูกต้องในการวางโปรเจ็กต์ของคุณ ช่วยให้คิดว่า WSL2 ไม่ใช่เป็น “Linux ใน Windows” แต่เป็นระบบ Linux แยกต่างหากที่รวมเข้ากับ Windows ได้ดี
เมื่อคุณใช้โมเดลนั้น การตัดสินใจของระบบไฟล์จะชัดเจน โดยปกติแล้วคุณจะไม่พัฒนาโปรเจ็กต์ Linux บนระบบไฟล์ที่ติดตั้งบนเครือข่ายซึ่งมีเวลาแฝงสูง คุณจะเก็บมันไว้ในท้องถิ่น ใน WSL2 ระบบไฟล์ Linux คือสภาพแวดล้อมภายในเครื่องของคุณ และระบบไฟล์ Windows จะอยู่ในระยะไกลอย่างมีประสิทธิภาพจากมุมมองของ Linux
การแก้ไขใช้เวลาไม่กี่นาที
ย้ายโปรเจ็กต์หรือโคลนภายในระบบไฟล์ Linux
การแก้ปัญหาไม่ซับซ้อน คุณเพียงแค่ต้องย้ายโครงการของคุณ:
mv /mnt/c/Users/YourName/projects/my-app ~/projects/
หรือจำลองใหม่โดยตรงภายใน WSL2:
git clone <repo>
~/projects/my-app
อัปเดตโปรแกรมแก้ไขของคุณเพื่อเปิดตำแหน่งใหม่
ประสิทธิภาพขึ้นอยู่กับตำแหน่งมากกว่าการปรับแต่ง
WSL2 ทำงานได้ดีที่สุดเมื่อถือเป็นสภาพแวดล้อม Linux ที่สมบูรณ์โดยคำนึงถึงขอบเขตภายในของตัวเอง ทันทีที่โปรเจ็กต์อยู่ในพื้นที่นั้น ความขัดแย้งส่วนใหญ่ที่เกี่ยวข้องกับเวิร์กโฟลว์แบบไฮบริดจะจางหายไป Windows ยังคงมีประโยชน์ในฐานะเลเยอร์อินเทอร์เฟซ แต่บริบทการดำเนินการจะสอดคล้องกันอีกครั้ง และเครื่องมือจะทำงานตามที่ได้รับการออกแบบมาให้ทำงาน
ส่วนที่น่าสนใจคือต้องใช้ความพยายามเพียงเล็กน้อยในการไปถึงสภาวะนั้น การเปลี่ยนแปลงตำแหน่งจะเปลี่ยนแปลงประสิทธิภาพมากกว่าการปรับแต่งการกำหนดค่าส่วนใหญ่ที่เคยทำได้ เมื่อกลายมาเป็นสัญชาตญาณ พฤติกรรมก่อนหน้านี้จะเริ่มดูเหมือนลึกลับน้อยลง และเป็นเหมือนผลลัพธ์ที่คาดเดาได้ของการข้ามระบบที่ไม่เคยได้รับการปรับให้เหมาะสมสำหรับการเข้าถึงไปมาอย่างต่อเนื่อง
*️⃣ ลิงค์ที่มา:
ระบบไฟล์, WSL นั้นดี แต่ก็ยังไม่เพียงพอสำหรับฉันที่จะกลับไปใช้ Windows , 5 คุณสมบัติ Git ที่ให้ความรู้สึกเหมือนโกงจริงๆ , webpack, ส่วนขยาย WSL ระยะไกล ,