การรวบรวมไฟล์ C ++ ใช้เวลานานมากเมื่อเทียบกับ C # และ Java การคอมไพล์ไฟล์ C ++ ใช้เวลานานกว่าการรันสคริปต์ Python ขนาดปกติ ขณะนี้ฉันใช้ VC ++ แต่ก็เหมือนกันกับคอมไพเลอร์ใด ๆ ทำไมนี้

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

หลากหลายเหตุผล

ไฟล์ส่วนหัว

หน่วยการรวบรวมเดียวทุกหน่วยต้องมีส่วนหัวเป็นร้อยหรือหลายพันเพื่อให้โหลด (1) และ (2) รวบรวม โดยทั่วไปทุก ๆ หน่วยจะต้องทำการคอมไพล์ใหม่สำหรับทุกหน่วยการคอมไพล์เนื่องจากตัวประมวลผลล่วงหน้าทำให้แน่ใจว่าผลลัพธ์ของการรวบรวมส่วนหัวอาจแตกต่างกันระหว่างหน่วยการรวบรวมทั้งหมด (อาจกำหนดแมโครในหนึ่งหน่วยการคอมไพล์ซึ่งเปลี่ยนเนื้อหาของส่วนหัว)

นี่อาจเป็นเหตุผลหลักเนื่องจากต้องมีการรวบรวมรหัสจำนวนมากสำหรับทุกหน่วยการรวบรวมและนอกจากนี้ทุกส่วนหัวจะต้องรวบรวมหลายครั้ง (ครั้งเดียวสำหรับทุกหน่วยการรวบรวมที่มี)

การเชื่อมโยง

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

วจีวิภาค

ไวยากรณ์มีความซับซ้อนอย่างมากในการแยกวิเคราะห์ขึ้นอยู่กับบริบทและยากที่จะแยกแยะ ใช้เวลานานมาก

แม่แบบ

ใน C # List<T>เป็นประเภทเดียวที่ถูกคอมไพล์ไม่ว่าคุณมีรายการอินสแตนซ์จำนวนเท่าใดในโปรแกรมของคุณ ใน C ++ vector<int>เป็นประเภทที่แยกจากกันโดยสิ้นเชิงvector<float>และแต่ละประเภทจะต้องรวบรวมแยกต่างหาก

เพิ่มไปที่เทมเพลตประกอบขึ้นเป็น "ภาษาย่อย" ที่ทัวริงสมบูรณ์ซึ่งคอมไพเลอร์ต้องตีความและสิ่งนี้อาจซับซ้อนอย่างน่าขัน แม้แต่รหัส metaprogramming แม่แบบที่ค่อนข้างง่ายยังสามารถกำหนดแม่แบบเวียนเกิดที่สร้างอินสแตนซ์ของแม่แบบได้หลายสิบครั้ง เทมเพลตอาจส่งผลให้เกิดประเภทที่ซับซ้อนอย่างยิ่งโดยมีชื่อยาว ๆ น่าขันซึ่งเป็นการเพิ่มงานพิเศษจำนวนมากให้กับลิงเกอร์ (ต้องเปรียบเทียบชื่อสัญลักษณ์จำนวนมากและหากชื่อเหล่านี้สามารถเติบโตได้หลายพันตัวอักษรนั่นอาจมีราคาแพงพอสมควร)

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

การเพิ่มประสิทธิภาพ

C ++ ช่วยให้สามารถปรับแต่งได้อย่างน่าทึ่ง C # หรือ Java ไม่อนุญาตให้คลาสถูกกำจัดอย่างสมบูรณ์ (ต้องอยู่ที่นั่นเพื่อจุดประสงค์ในการสะท้อนกลับ) แต่แม้กระทั่งเทมเพลต C ++ เทมเพลต C ++ ที่เรียบง่ายสามารถสร้างคลาสได้อย่างง่ายดายหลายสิบหรือหลายร้อยคลาส ระยะ

ยิ่งไปกว่านั้นโปรแกรม C ++ ต้องได้รับการปรับให้เหมาะสมที่สุดโดยคอมไพเลอร์ โปรแกรม AC # สามารถพึ่งพาคอมไพเลอร์ JIT เพื่อดำเนินการเพิ่มประสิทธิภาพเพิ่มเติม ณ เวลาโหลด C ++ ไม่ได้รับ "โอกาสครั้งที่สอง" สิ่งที่คอมไพเลอร์สร้างนั้นได้รับการปรับให้เหมาะสมที่สุดเท่าที่จะเป็นไปได้

เครื่อง

C ++ ถูกคอมไพล์ไปยังรหัสเครื่องซึ่งอาจจะค่อนข้างซับซ้อนกว่าการใช้ bytecode Java หรือ. NET (โดยเฉพาะในกรณีของ x86) (สิ่งนี้ถูกกล่าวถึงว่าไม่สมบูรณ์เนื่องจากมีการกล่าวถึงในความคิดเห็นและในทางปฏิบัติขั้นตอนนี้ไม่น่าจะใช้เวลานานกว่าการรวบรวมเพียงเล็กน้อย)

ข้อสรุป

ปัจจัยเหล่านี้ส่วนใหญ่ใช้ร่วมกันโดยรหัส C ซึ่งจริง ๆ แล้วรวบรวมอย่างมีประสิทธิภาพ ขั้นตอนการวิเคราะห์คำมีความซับซ้อนมากขึ้นใน C ++ และอาจใช้เวลานานขึ้นอย่างมาก แต่ผู้กระทำผิดหลักน่าจะเป็นแม่แบบ พวกมันมีประโยชน์และทำให้ภาษา C ++ เป็นภาษาที่ทรงพลังยิ่งกว่าเดิม แต่พวกเขายังต้องเสียเวลาในการรวบรวมความเร็ว

การชะลอตัวไม่จำเป็นต้องเหมือนกันกับคอมไพเลอร์ใด ๆ

ฉันไม่ได้ใช้ Delphi หรือ Kylix แต่ย้อนกลับไปในวันที่ MS-DOS โปรแกรม Turbo Pascal จะรวบรวมเกือบทันทีในขณะที่โปรแกรม Turbo C ++ ที่เทียบเท่าจะคลาน

ความแตกต่างที่สำคัญสองประการคือระบบโมดูลที่แข็งแกร่งมากและไวยากรณ์ที่อนุญาตการรวบรวมแบบ Single-Pass

เป็นไปได้อย่างแน่นอนว่าความเร็วในการรวบรวมนั้นไม่ได้มีความสำคัญสำหรับนักพัฒนาคอมไพเลอร์ C ++ แต่ก็มีปัญหาแทรกซ้อนบางอย่างในไวยากรณ์ C / C ++ ที่ทำให้ยากต่อการประมวลผล (ฉันไม่ใช่ผู้เชี่ยวชาญใน C แต่ Walter Bright คือและหลังจากสร้างคอมไพเลอร์ C / C ++ เชิงพาณิชย์หลาย ๆ ตัวเขาได้สร้างภาษา D หนึ่งในการเปลี่ยนแปลงของเขาคือการบังคับใช้ไวยากรณ์แบบไม่มีบริบทเพื่อให้ง่ายต่อการแยกภาษา .)

นอกจากนี้คุณจะสังเกตเห็นว่าโดยทั่วไป Makefiles ถูกตั้งค่าเพื่อให้ทุกไฟล์ถูกคอมไพล์แยกกันใน C ดังนั้นหากไฟล์ต้นฉบับ 10 ไฟล์ใช้ไฟล์รวมเดียวกันไฟล์นั้นจะถูกประมวลผล 10 ครั้ง

การแยกวิเคราะห์และการสร้างรหัสค่อนข้างเร็ว ปัญหาที่แท้จริงคือการเปิดและปิดไฟล์ โปรดจำไว้ว่าแม้จะมียามรวมคอมไพเลอร์ก็ยังคงเปิดไฟล์. H และอ่านแต่ละบรรทัด (และจากนั้นไม่สนใจ)

เพื่อนคนหนึ่ง (ในขณะที่เบื่อที่ทำงาน) นำใบสมัครของ บริษัท ของเขาและนำทุกอย่าง - ไฟล์ต้นฉบับและไฟล์ส่วนหัว - เป็นไฟล์ขนาดใหญ่ไฟล์เดียว เวลารวบรวมลดลงจาก 3 ชั่วโมงเป็น 7 นาที

อีกเหตุผลหนึ่งคือการใช้ตัวประมวลผลล่วงหน้า C สำหรับการค้นหาการประกาศ แม้จะมียามหัว, .h ยังคงต้องมีการแยกวิเคราะห์ซ้ำแล้วซ้ำอีกทุกครั้งที่พวกเขารวม คอมไพเลอร์บางตัวรองรับส่วนหัวที่รวบรวมไว้ล่วงหน้าซึ่งสามารถช่วยได้ แต่ก็ไม่ได้ใช้งานเสมอไป

ดูเพิ่มเติม: C ++ คำตอบที่พบบ่อย

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

Java และ C # รวบรวมเป็น byte-code / IL และเครื่องเสมือน Java /. NET Framework ดำเนินการ (หรือรวบรวม JIT เป็นรหัสเครื่อง) ก่อนดำเนินการ

Python เป็นภาษาตีความที่รวบรวมไว้เป็นรหัสไบต์

ฉันแน่ใจว่ามีเหตุผลอื่นสำหรับเรื่องนี้เช่นกัน แต่โดยทั่วไปไม่ต้องคอมไพล์เป็นภาษาเครื่องดั้งเดิมช่วยประหยัดเวลา

ปัญหาที่ใหญ่ที่สุดคือ:

1) การวิเคราะห์ส่วนหัวที่ไม่สิ้นสุด พูดถึงแล้ว การบรรเทา (เช่น #pragma หนึ่งครั้ง) มักจะทำงานต่อหน่วยการรวบรวมเท่านั้นไม่ใช่ต่อการสร้าง

2) ความจริงที่ว่า toolchain มักจะถูกแยกออกเป็นหลาย ๆ ไบนารี (ทำ, preprocessor, คอมไพเลอร์, แอสเซมเบลอร์, archiver, impdef, linker และ dlltool ในกรณีที่รุนแรง) ที่ทุกคนต้องเริ่มต้นใหม่และโหลดทุกสถานะตลอดเวลา คอมไพเลอร์แอสเซมเบลอร์) หรือไฟล์ทุกคู่ (archiver, linker และ dlltool)

ดูการสนทนานี้ใน comp.compilers: http://compilers.iecc.com/comparch/article/03-11-078โดยเฉพาะอันนี้

http://compilers.iecc.com/comparch/article/02-07-128

โปรดทราบว่า John ผู้ดำเนินการของ comp.compilers นั้นเห็นด้วยและนั่นหมายความว่ามันควรจะเป็นไปได้ที่จะบรรลุความเร็วที่ใกล้เคียงกันสำหรับ C เช่นกันหากมีการรวม toolchain อย่างสมบูรณ์และใช้ส่วนหัวที่คอมไพล์แล้วล่วงหน้า คอมไพเลอร์ C เชิงพาณิชย์จำนวนมากทำสิ่งนี้ในระดับหนึ่ง

โปรดทราบว่ารูปแบบ Unix ของการแยกตัวประกอบทุกอย่างออกเป็นไบนารีแยกเป็นรูปแบบตัวพิมพ์ที่แย่ที่สุดสำหรับ Windows (ด้วยการสร้างกระบวนการที่ช้า) เป็นสิ่งที่น่าสังเกตมากเมื่อเปรียบเทียบเวลาในการสร้าง GCC ระหว่าง Windows กับ * ระวังโดยเฉพาะอย่างยิ่งหากระบบ make / configure เรียกใช้บางโปรแกรมเพื่อรับข้อมูล

อาคาร C / C ++: เกิดอะไรขึ้นจริงและทำไมมันใช้เวลานานมาก

เวลาส่วนใหญ่ในการพัฒนาซอฟต์แวร์ไม่ได้ถูกใช้ในการเขียน, รัน, ดีบั๊กหรือแม้กระทั่งการออกแบบรหัส แต่รอให้การคอมไพล์เสร็จสิ้น ก่อนอื่นเราต้องเข้าใจว่าเกิดอะไรขึ้นเมื่อคอมไพล์ซอฟต์แวร์ C / C ++ ขั้นตอนคร่าว ๆ ดังนี้:

• องค์ประกอบ
• สร้างเครื่องมือเริ่มต้น
• การตรวจสอบการพึ่งพา
• การรวบรวม
• การเชื่อมโยง

ตอนนี้เราจะพิจารณาแต่ละขั้นตอนอย่างละเอียดโดยเน้นที่วิธีการที่จะทำให้เร็วขึ้น

องค์ประกอบ

นี่เป็นขั้นตอนแรกเมื่อเริ่มสร้าง โดยปกติแล้วหมายถึงการรันสคริปต์กำหนดค่าหรือ CMake, Gyp, SCons หรือเครื่องมืออื่น ๆ สิ่งนี้อาจใช้เวลาตั้งแต่หนึ่งวินาทีถึงหลายนาทีในการกำหนดค่าสคริปต์ที่ใช้ Autotools ขนาดใหญ่มาก

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

สร้างเครื่องมือเริ่มต้น

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

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

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

การตรวจสอบการพึ่งพา

เมื่อเครื่องมือสร้างอ่านการกำหนดค่าแล้วมันจะต้องพิจารณาว่าไฟล์ใดที่มีการเปลี่ยนแปลงและไฟล์ใดที่ต้องทำการคอมไพล์ใหม่ ไฟล์การกำหนดค่ามีกราฟ acyclic กำกับที่อธิบายถึงการพึ่งพาการสร้าง โดยปกติแล้วกราฟนี้จะถูกสร้างขึ้นในระหว่างขั้นตอนการกำหนดค่า เวลาเริ่มต้นเครื่องมือสร้างและสแกนเนอร์อ้างอิงจะทำงานในทุกบิลด์เดียว รันไทม์ที่รวมกันของพวกเขาจะกำหนดขอบเขตที่ต่ำกว่าในวงจรการแก้ไข สำหรับโครงการขนาดเล็กเวลานี้มักจะไม่กี่วินาทีหรือดังนั้น สิ่งนี้ทนได้ มีทางเลือกในการทำ เร็วที่สุดคือ Ninja ซึ่งสร้างโดยวิศวกร Google สำหรับ Chromium หากคุณใช้ CMake หรือ Gyp เพื่อสร้างเพียงสลับไปที่แบ็กเอนด์นินจาของพวกเขา คุณไม่จำเป็นต้องเปลี่ยนแปลงอะไรในไฟล์บิลด์ด้วยตัวเองเพียงแค่สนุกกับการเพิ่มความเร็ว Ninja ไม่ได้บรรจุในการแจกแจงส่วนใหญ่

การรวบรวม

ณ จุดนี้ในที่สุดเราก็เรียกคอมไพเลอร์ การตัดมุมบางส่วนนี่คือขั้นตอนโดยประมาณ

• การผสานรวม
• การแยกรหัส
• การสร้างรหัส / การปรับให้เหมาะสม

ตรงกันข้ามกับความเชื่อที่ได้รับความนิยมการรวบรวม C ++ ไม่ใช่สิ่งที่ช้าอย่างแท้จริง STL ช้าและเครื่องมือสร้างส่วนใหญ่ที่ใช้ในการคอมไพล์ C ++ นั้นช้า อย่างไรก็ตามมีเครื่องมือและวิธีการที่รวดเร็วกว่าในการลดส่วนที่ช้าของภาษา

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

ภาษาที่รวบรวมจะต้องใช้ค่าเริ่มต้นที่ใหญ่กว่าภาษาที่ตีความ นอกจากนี้บางทีคุณอาจไม่ได้จัดโครงสร้างโค้ด C ++ ของคุณไว้อย่างดี ตัวอย่างเช่น:

#include "BigClass.h"

class SmallClass
{
   BigClass m_bigClass;
}

รวบรวมช้ากว่ามาก:

class BigClass;

class SmallClass
{
   BigClass* m_bigClass;
}

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

ตัวอย่างเช่นสมมติว่าคุณมี a.cpp, b.cpp และ c.cpp .. สร้างไฟล์: everything.cpp:

#include "a.cpp"
#include "b.cpp"
#include "c.cpp"

จากนั้นรวบรวมโครงการโดยทำทุกอย่าง

เหตุผลบางประการคือ:

1) ไวยากรณ์ C ++ นั้นซับซ้อนกว่า C # หรือ Java และใช้เวลาในการวิเคราะห์มากขึ้น

2) (สำคัญกว่า) คอมไพเลอร์ C ++ สร้างรหัสเครื่องและทำการปรับแต่งทั้งหมดในระหว่างการรวบรวม C # และ Java ไปครึ่งทางและออกจากขั้นตอนเหล่านี้ไปที่ JIT

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

คำตอบส่วนใหญ่ยังไม่ชัดเจนในการกล่าวถึงว่า C # จะทำงานช้าลงเนื่องจากต้นทุนของการดำเนินการที่ใน C ++ ดำเนินการเพียงครั้งเดียวในเวลารวบรวมค่าใช้จ่ายประสิทธิภาพการทำงานนี้ยังได้รับผลกระทบเนื่องจากการพึ่งพารันไทม์ เพื่อเรียกใช้) ไม่ต้องพูดถึงว่าโปรแกรม C # จะมีหน่วยความจำสูงกว่าเสมอซึ่งส่งผลให้ประสิทธิภาพมีความสัมพันธ์อย่างใกล้ชิดกับความสามารถของฮาร์ดแวร์ที่มีให้ เช่นเดียวกับภาษาอื่นที่ตีความหรือพึ่งพา VM

มีสองประเด็นที่ฉันคิดว่าอาจมีผลต่อความเร็วที่โปรแกรมของคุณใน C ++ รวบรวม

ปัญหาที่เป็นไปได้ # 1 - การรวบรวม HEADER: (นี่อาจหรืออาจไม่ได้รับการแก้ไขแล้วโดยคำตอบหรือความคิดเห็นอื่น) Microsoft Visual C ++ (AKA VC ++) สนับสนุนส่วนหัวที่คอมไพล์แล้วซึ่งฉันขอแนะนำเป็นอย่างยิ่ง เมื่อคุณสร้างโครงการใหม่และเลือกประเภทของโปรแกรมที่คุณทำหน้าต่างตัวช่วยสร้างการตั้งค่าควรปรากฏขึ้นบนหน้าจอของคุณ หากคุณกดปุ่ม "ถัดไป>" ที่ด้านล่างหน้าต่างจะนำคุณไปยังหน้าที่มีรายการคุณลักษณะหลายอย่าง ตรวจสอบให้แน่ใจว่าได้ทำเครื่องหมายในช่องถัดจากตัวเลือก“ ส่วนหัวที่คอมไพล์แล้ว” (หมายเหตุ: นี่เป็นประสบการณ์ของฉันกับแอปพลิเคชันคอนโซลของ Win32 ใน C ++ แต่อาจไม่เป็นกรณีของโปรแกรมทุกชนิดใน C ++)

ปัญหาที่เป็นไปได้ # 2 - สถานที่ตั้งรวบรวม:ฤดูร้อนนี้ฉันเรียนหลักสูตรการเขียนโปรแกรมและเราต้องจัดเก็บโครงการทั้งหมดของเราในแฟลชไดรฟ์ 8GB เนื่องจากคอมพิวเตอร์ในห้องปฏิบัติการที่เราใช้ถูกเช็ดทุกคืนในเวลาเที่ยงคืน ซึ่งจะลบงานทั้งหมดของเรา หากคุณกำลังรวบรวมอุปกรณ์เก็บข้อมูลภายนอกเพื่อประโยชน์ในการพกพา / ความปลอดภัย / ฯลฯ อาจใช้เวลานานมากเวลา (แม้จะมีส่วนหัวที่คอมไพล์แล้วที่ฉันได้กล่าวไว้ข้างต้น) เพื่อให้โปรแกรมของคุณรวบรวมโดยเฉพาะอย่างยิ่งหากเป็นโปรแกรมที่ค่อนข้างใหญ่ คำแนะนำของฉันสำหรับคุณในกรณีนี้คือการสร้างและรวบรวมโปรแกรมบนฮาร์ดไดรฟ์ของคอมพิวเตอร์ที่คุณใช้และเมื่อใดก็ตามที่คุณต้องการ / จำเป็นต้องหยุดทำงานในโครงการของคุณด้วยเหตุผลใดก็ตามให้โอนไปยังภายนอกของคุณ อุปกรณ์จัดเก็บข้อมูลจากนั้นคลิกไอคอน“ Safely Remove Hardware และ Eject Media” ซึ่งควรปรากฏเป็นแฟลชไดรฟ์ขนาดเล็กด้านหลังวงกลมสีเขียวเล็ก ๆ ที่มีเครื่องหมายสีขาวติดอยู่เพื่อยกเลิกการเชื่อมต่อ

ฉันหวังว่านี่จะช่วยคุณได้ แจ้งให้เราทราบหากมัน! :)