ฉันควรคอมไพล์รุ่นที่มีข้อมูลการแก้ไขข้อบกพร่องเป็น "เต็ม" หรือ "เฉพาะ pdb"

114

ใน Visual Studio 2010 สำหรับโครงการ C # ถ้าคุณไปที่คุณสมบัติโครงการ> สร้าง> ขั้นสูง> ข้อมูลการดีบักคุณมีสามตัวเลือก: ไม่มีเต็มหรือเฉพาะ pdb จากคำตอบของคำถามนี้ฉันเชื่อว่าฉันเข้าใจความแตกต่างบางประการระหว่าง full และ pdb-only อย่างไรก็ตามแบบใดเหมาะสมกว่าสำหรับรุ่นรีลีส ถ้าฉันใช้ "เต็ม" จะมีการแบ่งประสิทธิภาพหรือไม่ ถ้าฉันใช้ "pdb-only" จะแก้ไขปัญหาการผลิตได้ยากขึ้นหรือไม่

"full" กับ "pdbonly" ต่างกันอย่างไร? https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/debug-compiler-option

— RationalGeek
แหล่งที่มา

pdb-only หรือ none เสมอสำหรับรุ่น release

— leppie

13

@leppie ขอบคุณ แต่ฉันกำลังมองหาเหตุผลบางอย่างของตำแหน่งนั้น

— RationalGeek

คำถามที่เกี่ยวข้อง: stackoverflow.com/questions/1270986/…

— janv8000

ดีมากถ้าไม่มีผลกระทบด้านประสิทธิภาพ สิ่งที่เกี่ยวกับผลกระทบของหน่วยความจำ? ถ้าฉันสร้างอินสแตนซ์ของ StackTrace และขอข้อมูลไฟล์มันต้องมาจากข้อมูลสัญลักษณ์ pdb สัญลักษณ์ทั้งหมดถูกโหลดลงในหน่วยความจำเมื่อแอปพลิเคชันเริ่มทำงานหรือไม่ การใช้หน่วยความจำโดยประมาณคืออะไร? (เช่นเปอร์เซ็นต์ค่าโสหุ้ยเทียบกับขนาดโค้ด)

— โยโย่

90

ฉันจะสร้างด้วยpdb-only. คุณจะไม่สามารถแนบดีบักเกอร์กับผลิตภัณฑ์ที่นำออกใช้ แต่ถ้าคุณได้รับการถ่ายโอนข้อมูลความผิดพลาดคุณสามารถใช้ Visual Studio หรือWinDBGเพื่อตรวจสอบการติดตามสแต็กและการทิ้งหน่วยความจำในเวลาที่เกิดข้อขัดข้อง

หากคุณfullใช้มากกว่าpdb-onlyคุณจะได้รับสิทธิประโยชน์เหมือนกันยกเว้นว่าสามารถแนบไฟล์ปฏิบัติการกับดีบักเกอร์ได้โดยตรง คุณจะต้องพิจารณาว่าสิ่งนี้สมเหตุสมผลกับผลิตภัณฑ์และลูกค้าของคุณหรือไม่

อย่าลืมบันทึกไฟล์ PDB ไว้ที่ใดที่หนึ่งเพื่อให้คุณสามารถอ้างอิงได้เมื่อมีรายงานข้อขัดข้องหากคุณสามารถตั้งค่าเซิร์ฟเวอร์สัญลักษณ์เพื่อจัดเก็บสัญลักษณ์การดีบักเหล่านั้นได้มากก็ยิ่งดี

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

หมายเหตุเกี่ยวกับประสิทธิภาพ:

ทั้งจอห์นร็อบบินส์และเอริค Lippertได้เขียนบล็อกโพสต์เกี่ยวกับ/debugธงและพวกเขาทั้งสองแสดงให้เห็นว่าการตั้งค่านี้มีศูนย์ผลกระทบต่อประสิทธิภาพ มี/optimizeแฟล็กแยกต่างหากซึ่งกำหนดว่าคอมไพลเลอร์ควรดำเนินการปรับให้เหมาะสมหรือไม่

— แมตต์ดิลลาร์ด
แหล่งที่มา

7

@Matt บทความ MSDN เกี่ยวกับสวิตช์ / debugเตือนอย่างชัดเจนเกี่ยวกับผลกระทบด้านประสิทธิภาพของการใช้การตั้งค่า 'เต็ม':

If you use /debug:full, be aware that there is some impact on the speed and size of JIT optimized code and a small impact on code quality with /debug:full. We recommend /debug:pdbonly or no PDB for generating release code.

— Allon Guralnek

3

@Matt: ถ้า 'เต็ม' ไม่มีข้อเสียเมื่อเทียบกับ 'pdb-only' แต่มีข้อดีเท่านั้นทำไม 'pdb-only' ถึงมีอยู่? มีเหตุผลอะไรที่จะใช้เกิน "เต็ม" หรือไม่? นอกจากนี้คุณควรเพิ่มการแก้ไขในบทความ MSDN ในส่วน "เนื้อหาชุมชน"

— Allon Guralnek

9

@AllonGuralnek อ้างจากบทความ John Robbins ที่เชื่อมโยง: เหตุผลที่แท้จริง: ประวัติศาสตร์ ย้อนกลับไปใน. NET 1.0 มีความแตกต่าง แต่ใน. NET 2.0 นั้นไม่มี ดูเหมือนว่า. NET 4.0 จะเป็นไปตามรูปแบบเดียวกัน หลังจากตรวจสอบซ้ำกับทีมดีบัก CLR แล้วไม่มีความแตกต่างเลย

— bentayloruk

5

นี่ไม่เป็นความจริง คุณสามารถสร้างด้วย pdb เท่านั้นและยังแนบดีบักเกอร์ ฉันแค่ทำเพื่อความแน่ใจ

— มาร์ค

2

"ฉันจะสร้างด้วย pdb เท่านั้นคุณจะไม่สามารถแนบดีบักเกอร์กับผลิตภัณฑ์ที่วางจำหน่ายได้" แหล่งข้อมูลของคุณที่นี่คืออะไร? ตามที่ทั้ง @Mark และฉันได้ตั้งข้อสังเกตสิ่งนี้ดูเหมือนจะไม่ถูกต้อง

— MEMark

66

คำเตือนเอกสาร MSDN สำหรับ / debug switch (ใน Visual Studio คือ Debug Info) ดูเหมือนจะล้าสมัย! นี่คือสิ่งที่มีซึ่งไม่ถูกต้อง

ถ้าคุณใช้ / การแก้ปัญหา: เต็มจะทราบว่ามีผลกระทบบางอย่างเกี่ยวกับความเร็วและขนาดของการเพิ่มประสิทธิภาพ JIT รหัสและผลกระทบที่มีต่อคุณภาพขนาดเล็กรหัสด้วย / แก้ปัญหา: เต็มรูปแบบ เราขอแนะนำ / การแก้ปัญหา: pdbonlyหรือ PDB รหัสที่ก่อให้เกิดการปล่อยไม่มี

ความแตกต่างอย่างหนึ่งระหว่าง / debug: pdbonlyและ / debug: fullคือด้วย / debug: full คอมไพเลอร์จะปล่อย a DebuggableAttributeซึ่งใช้เพื่อบอกคอมไพเลอร์ JIT ว่ามีข้อมูลการดีบัก

แล้วสิ่งที่เป็นจริงตอนนี้?

Pdb-only - ก่อนหน้า. NET 2.0 ช่วยในการตรวจสอบการทิ้งข้อขัดข้องจากผลิตภัณฑ์ที่วางจำหน่าย (เครื่องของลูกค้า) แต่มันไม่ยอมให้ติดดีบักเกอร์ นี่ไม่ใช่กรณีจาก. NET 2.0 มันเป็นตรงเช่นเดียวกับแบบเต็ม
เต็ม - นี้จะช่วยให้เราสามารถตรวจสอบความผิดพลาดทิ้งและยังช่วยให้เราสามารถแนบการดีบักเกอร์ที่จะปล่อยสร้าง แต่ต่างจากที่ MSDN กล่าวถึง แต่จะไม่ส่งผลกระทบต่อประสิทธิภาพการทำงาน (ตั้งแต่. NET 2.0) มันไม่เหมือนกันตรงตามที่PDB เท่านั้น

ถ้าเหมือนกันทุกประการทำไมเราถึงมีตัวเลือกเหล่านี้ John Robbins (windows debugging god) ค้นพบสิ่งเหล่านี้มีเหตุผลทางประวัติศาสตร์

ย้อนกลับไปใน. NET 1.0 มีความแตกต่าง แต่ใน. NET 2.0 นั้นไม่มี ดูเหมือนว่า. NET 4.0 จะเป็นไปตามรูปแบบเดียวกัน หลังจากตรวจสอบซ้ำกับทีมดีบัก CLR แล้วไม่มีความแตกต่างเลย

สิ่งที่ควบคุมว่า JITter สร้าง debug หรือไม่คือสวิตช์ / optimize < ... >

บรรทัดล่างคือคุณต้องการสร้างรุ่นของคุณด้วย / optimize + และสวิตช์ / debug ใด ๆ เพื่อให้คุณสามารถดีบักด้วยซอร์สโค้ดได้

จากนั้นเขาก็พิสูจน์ต่อไป

ตอนนี้การเพิ่มประสิทธิภาพเป็นส่วนหนึ่งของสวิตช์แยกต่างหาก/optimize(เรียกว่า Visual Studio Optimize code)

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

— rpattabi
แหล่งที่มา

3

คำตอบสุดวิเศษ! การตรวจสอบของฉันเอง (เปรียบเทียบไฟล์ที่สร้างขึ้น) แสดงผลลัพธ์เหมือนกัน

— MEMark

@rpattabi คุณสามารถระบุ reference ว่า pdbonly และ full เหมือนกันได้หรือไม่? เป็นปี 2019 และเอกสารยังคงระบุว่าแตกต่างกันและเต็มจะมีประสิทธิภาพลดลง และ VS2019 สร้างโครงการที่มีReleasedebugtype pdbonlyการกำหนดค่าโดยการตั้งค่าเริ่มต้น

— โจ

@ Joe มีการอภิปรายที่ด้านล่างของ MSDN เอกสารเป็นmsdn.microsoft.com/en-us/library/8cw0bt21.aspx ลองดูที่มัน ผู้ร่วมให้ข้อมูลรายหนึ่งชี้ไปที่github.com/dotnet/roslyn/blob/master/docs/compilers/CSharp/…สำหรับข้อมูลล่าสุดที่กล่าวถึง pdbonly และ full เหมือนกัน (FYI ฉันไม่ได้ใช้ windows หรือ VS อีกต่อไปดังนั้นฉันจึงไม่ได้ติดตามสิ่งที่เกิดขึ้นที่นั่น แต่เมื่อฉันตรวจสอบข้อมูลในคำตอบของฉันยังคงเกี่ยวข้องและเอกสาร MSDN ยังไม่ถูกต้อง)

— rpattabi

16

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

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

— blowdart
แหล่งที่มา

มีเหตุผล. ฉันไม่ได้แจกจ่าย DLL ให้กับผู้ใช้อย่างแท้จริง แต่เป็นแอป ASP.NET แต่คุณสามารถปรับปรุงคำตอบของคุณและให้เหตุผลว่าทำไมคุณควรเลือกใช้ "pdb-only" กับ "full" เป็นปัญหาด้านประสิทธิภาพหรือไม่?

— RationalGeek

@jkohlhepp: ฉันต้องการเพิ่มแม้ว่าการสร้างรุ่นการแก้จุดบกพร่องจะค่อนข้างยุ่งยากเนื่องจากคุณจะสูญเสียข้อมูลบางอย่าง (เนื่องจาก JIT) เกือบตลอดเวลาคุณจะไม่สามารถเห็นค่าของอาร์กิวเมนต์เมธอดได้ เมื่อต้องการแก้ปัญหานี้คุณเพิ่มประสิทธิภาพ JIT ปิดการใช้งานชั่วคราวสามารถใช้นี้

— Ilian Pinzon

ขอบคุณ blowdart และขอบคุณ Ilian Pinzon สำหรับข้อมูลเพิ่มเติม ฉันรู้ว่าคุณไม่สามารถแก้ไขจุดบกพร่องได้อย่างสมบูรณ์แบบด้วยรหัสรุ่น แต่การมี PDB นั้นดีกว่าไม่มีอะไรเลย

— RationalGeek

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

— Matt Dillard

1

คำถามดีๆเกี่ยวกับ MSDN Matt, msdn.microsoft.com/en-us/library/8cw0bt21รอคำตอบด้วยตัวเอง

— Luke Hutton

4

ฉันอยู่ในขั้นตอนการเขียนตัวจัดการข้อยกเว้นที่ไม่สามารถจัดการได้และการติดตามสแต็กรวมถึงหมายเลขบรรทัดเมื่อใช้ pdb-only มิฉะนั้นฉันจะได้รับชื่อของ Sub / Function เมื่อฉันเลือกไม่มี

ถ้าฉันไม่แจกจ่าย. pdb ฉันไม่ได้รับหมายเลขบรรทัดในการติดตามสแต็กแม้ว่าจะมีการสร้างแบบ pdb เท่านั้นก็ตาม

ดังนั้นฉันกำลังแจกจ่าย (XCOPY ปรับใช้บน LAN) pdb พร้อมกับ exe จากแอป VB ของฉัน

— rheitzman
แหล่งที่มา