เหตุใดฉันจึงต้องใส่ใจเกี่ยวกับประสิทธิภาพของไมโครและประสิทธิภาพ?

71

คำถามและคำตอบมากมายในหน้า C / C ++ โดยเฉพาะหรือหารือเกี่ยวกับปัญหาประสิทธิภาพการทำงานของไมโคร (เช่นค่าใช้จ่ายของฟังก์ชั่น vs vs direct vs inline ทางอ้อม) หรือการใช้อัลกอริทึมO (N ² ) vs O (N log N) รายการ 100 รายการ

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

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

c++ c optimization code-organization

— ทิมโพสต์
แหล่งที่มา

5

+1 คำถามทั่วไปที่ดี

— iammilind

+1 คำถามที่ดี .. ฉันเพิ่ม 2 แท็ก .. หวังว่าคุณจะไม่สนใจ

2

ฉันมุ่งไปที่คำพูดที่ยอดเยี่ยมสองข้อ 1) "การเพิ่มประสิทธิภาพก่อนกำหนดเป็นรากของความชั่วร้ายทั้งหมด" 2) 80% ของเวลาของคุณจะถูกใช้ไปกับรหัส 20% ของคุณ (กฎ 80/20)

— James Khoury

2

ฉันสังเกตเห็นคำตอบสองสามข้อพูดคุยเกี่ยวกับตัวอย่าง O (n * n) ของฉัน ฉันระบุรายการ 100 รายการไว้อย่างชัดเจน แต่พวกเขายังคงยืนยันว่า O (nlogn) นั้นดีกว่าโดยระบุการปรับปรุงประสิทธิภาพอย่างชัดเจนหากรายการในรายการย่อยไปที่ 1,000 รายการหรือมากกว่านั้น นี่คือความลุ่มหลงในการเพิ่มประสิทธิภาพขนาดเล็กเพราะโปรแกรมเมอร์กำลังวางแผนความต้องการในอนาคตที่เป็นไปได้มากกว่าความต้องการที่แท้จริง (ฉันเคยได้ยินเรื่องนี้ที่ไหนมาก่อน ... )

— mattnz

5

@ James อ้างเต็ม ๆ จาก Donald Knuth คือ "เราควรลืมเกี่ยวกับประสิทธิภาพเล็กน้อยพูดประมาณ 97% ของเวลา: การเพิ่มประสิทธิภาพก่อนวัยอันควรเป็นรากฐานของความชั่วร้ายทั้งหมด" จะมีคำตอบที่ดีเกี่ยวกับ 3% ที่เหลือในชุดข้อความนี้

— StuperUser

14

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

หนึ่งในกับดักที่ง่ายที่สุดที่จะตกอยู่ใน - โดยเฉพาะใน C และ C ++ ที่คุณมีการควบคุมอย่างละเอียด - กำลังปรับให้เร็วเกินไปและอยู่ในระดับที่ดีเกินไป โดยทั่วไปแล้วกฎคือ: A) อย่าปรับให้เหมาะสมจนกว่าคุณจะพบว่าคุณมีปัญหาและ B) ไม่ปรับสิ่งที่คุณยังไม่ได้พิสูจน์ว่าเป็นปัญหาโดยการใช้ profiler

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

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

6

อีกอันหนึ่ง: รหัสการเริ่มต้นที่เรียกใช้ครั้งเดียวโดยทั่วไปไม่ต้องการการปรับให้เหมาะสมดังนั้นดูที่อื่น

— Mike DeSimone

3

ขึ้นอยู่กับความถี่ของ "ครั้งเดียว" เมื่อทำงาน./configureฉันจะกล้าพูดมากถึง 75% ของเวลาทำงานอาจใช้กับรหัส "การเริ่มต้น" ในโปรแกรมที่สคริปต์ทำงาน อาจใช้เวลา 25-50% ในการลิงก์แบบไดนามิก

— . ..

12

กฎ A เป็นกฎที่แย่มาก สถาปัตยกรรมของระบบมีบทบาทในการทำงานและหากคุณค้นพบภายหลังสถาปัตยกรรมของคุณก็ไม่สามารถรองรับความต้องการด้านประสิทธิภาพที่คุณได้รับ ดังนั้นในขณะที่คุณสามารถส่งผ่านรายละเอียดเล็ก ๆ น้อย ๆ ได้อย่างสมบูรณ์การละเว้นสิ่งนี้ในตอนเริ่มต้นนั้นเป็นเพียงความผิดปกติ

— edA-qa mort-ora-y

3

@ edA-qa: ฉันเคยคิดเช่นนั้น แต่ในช่วงหลายปีที่ผ่านมามีโครงการจำนวนมากที่ต้องดิ้นรนหรือล้มเหลวก่อนที่การพิจารณาเกี่ยวกับประสิทธิภาพจะกลายเป็นความกังวล ทุกครั้งที่ฉันมีข้อกังวลเกี่ยวกับประสิทธิภาพการแก้ไขนั้นมีค่าใช้จ่ายค่อนข้างต่ำวันหรือสองสามสัปดาห์ไม่ต้องกังวลมากไปกว่า "ข้อบกพร่อง" อื่น ๆ ที่ตรวจพบการแก้ไขในการพัฒนา อย่างไรก็ตาม jsut เหมือนกับรายการความเสี่ยงอื่น ๆ จำเป็นต้องระบุค่าประสิทธิภาพที่ลดลงในช่วงต้นของโครงการ

— mattnz

5

OP ถามว่าทำไมต้องใส่ใจมากมายและฉันก็ไม่เห็นว่าคำตอบนี้ตอบคำถามได้อย่างไรนอกเสียจากว่า OP มีความสนใจที่จะได้ยินใครบางคนพูดว่า "ไม่ต้องกังวลกับเรื่องนี้!"

— ดินสีแดง

54

ฉันคิดว่าทุกอย่างในรายการของคุณคือ micro-optimization ซึ่งโดยทั่วไปไม่ควรดูยกเว้น

ใช้อัลกอริทึม O (n * n) vs O (NlogN) ในรายการ 100 รายการ

ซึ่งฉันคิดว่าควรจะดู แน่นอนว่ารายการนั้นเป็น 100 รายการในตอนนี้และทุกอย่างรวดเร็วสำหรับ n ตัวเล็ก ๆแต่ฉันยินดีที่จะเดิมพันเร็ว ๆ นี้ว่ารหัสเดียวกันจะถูกนำมาใช้ซ้ำสำหรับรายการหลายล้านรายการและรหัสยังคงมีอยู่ ทำงานอย่างมีเหตุผล

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

— บิลลี่ออน
แหล่งที่มา

36

+1 สำหรับ "การเลือกอัลกอริทึมที่เหมาะสมไม่ใช่การเพิ่มประสิทธิภาพแบบไมโคร"

9

ฉัน +1 เช่นกัน แต่โปรดทราบว่าการเลือกอัลกอริทึม big-O- ที่ดีที่สุดเมื่อขนาดข้อมูลของคุณแน่ใจว่ามีขนาดเล็กอาจเป็นอันตรายต่อเวลาในการพัฒนาขนาดของโปรแกรมและแม้กระทั่งการใช้หน่วยความจำ หากคุณกำลังเรียงไพ่โป๊กเกอร์คุณต้องการเขียน quicksort, smoothsort หรือผสานหรือไม่? ฉันจะเริ่มต้นด้วยการเรียงลำดับการแทรกง่ายหรือใช้เครือข่ายการเรียงลำดับ

— ..

8

มันสนุก. ในหัวข้อเกี่ยวกับการเพิ่มประสิทธิภาพขนาดเล็กนักวิจารณ์จำนวนมากให้คำตอบอย่างเหมาะสม ;)

— รักษาความปลอดภัย

5

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

— nikie

3

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

— Casey Patton

18

เมื่อเวลาผ่านไป looooooong ในงานแรกของฉันฉันเขียนโค้ดสำหรับระบบฝังตัว ระบบเหล่านี้ใช้ไมโครโปรเซสเซอร์ 8086 และมีหน่วยความจำ จำกัด เราใช้คอมไพเลอร์ Intel C ระบบเดียวที่ฉันสร้างจำเป็นต้องใช้เพื่อเข้าถึงโครงสร้างแบบสามมิติ ฉันสร้างมันเหมือนที่หนังสือบอกฉัน: call malloc สำหรับ 3 มิติจากนั้นจัดสรรแถวสำหรับมิติถัดไปจากนั้น calloc สำหรับโหนดสุดท้าย

มันค่อนข้างซับซ้อน (สำหรับฉันในเวลานั้น) ฉันต้องทำส่วนโค้งการควบคุมกระบวนการ ANOVA และการวิเคราะห์แบบไคสแควร์ ไม่มีห้องสมุดที่ทำสิ่งนี้เพื่อเรา เราต้องเขียนทุกอย่างและใส่มันทั้งหมดลงใน 8086

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

ในอีกกรณีหนึ่งในงานเดียวกันลูกค้าก็บ่นเกี่ยวกับเวลาตอบสนองในระบบควบคุมกระบวนการทางสถิติของพวกเขา ทีมก่อนหน้าฉันได้ออกแบบระบบ "ซอฟต์แวร์ PLC" ซึ่งผู้ปฏิบัติงานสามารถใช้ตรรกะบูลีนสำหรับการรวมสัญญาณและสวิตช์ Tripping พวกเขาเขียนเป็นภาษาที่เข้าใจง่ายสิ่งที่เราเรียกว่า "ภาษาเฉพาะโดเมน" วันนี้ ในขณะที่ฉันจำได้ว่ามันดูเหมือน((A1 + B1) > 4) AND (C1 > C2)และอื่น ๆ

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

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

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

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

สิ่งต่าง ๆ เหล่านี้เกิดขึ้นตลอดเวลา

ดังนั้น .... บางครั้งคุณต้องการรหัสที่บำรุงรักษาง่ายต่อการเขียน บางครั้งคุณต้องการรหัสที่ทำงานได้อย่างรวดเร็ว ข้อดีคือการตัดสินใจทางวิศวกรรมที่คุณต้องทำในแต่ละโครงการ

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

9

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

— CodesInChaos

6

@CodeInChaos: คำตอบไม่ได้อ้างสิทธิ์เป็นอย่างอื่น มันพูดถึงคำถามของ OP "ทำไมฉันถึงควรใส่ใจเรื่องประสิทธิภาพและประสิทธิภาพของไมโคร" ปัญหาการปรับให้เหมาะสมก่อนหน้านั้นถูกอ้างถึงโดยผู้ตอบคำถามคนอื่นเท่านั้น

— webbiedave

12

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

— Steve Wellens
แหล่งที่มา

2

+1 - เช่นการเงินความถี่สูงการเข้ารหัส / ถอดรหัสเสียง / วิดีโอทุกชนิดการจำลองและการสร้างแบบจำลอง (เช่นเกม) บิตของระบบเช่นบิตซีพียูและตัวจัดการหน่วยความจำ ฯลฯ

— Billy ONeal

3

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

— เพียงแค่ความคิดเห็นที่ถูกต้องของฉัน

2

@ เพียงแค่ความคิดเห็นที่ถูกต้องของฉัน: จริงๆแล้วสำหรับการประมวลผลภาพการประมวลผลข้อมูลมักเป็นผู้บริโภครายใหญ่เป็นอันดับสอง (I / O ยังคงใหญ่ที่สุด) อย่างไรก็ตามการปรับให้เหมาะสมสำหรับ I / O นั้นจำเป็นต้องมีการออกแบบที่ผิดปกติ / บ้ามากและการยอมรับจากโปรแกรมเมอร์คนอื่น ๆ และบางครั้งก็เป็นไปไม่ได้เลยที่จะปรับปรุง อย่างไรก็ตามส่วนการประมวลผลมักจะขนานกันอย่างน่าอายดังนั้นพวกเขาจะได้ประโยชน์ได้อย่างง่ายดาย reapable (tweaking หนึ่งของอาจถูกมองว่าเป็นอีกหนึ่งการดำเนินการตามตำราเรียนตรง ... เว้นแต่คุณจะถึงระดับของ VirtualDub)

— rwong

12

ฉันจะบอกคุณเล็กน้อยเกี่ยวกับสาเหตุที่อยู่เบื้องหลังวัฒนธรรม

หากคุณอยู่ใกล้กับ 40 ถึง 20 และคุณเคยเขียนโปรแกรมเพื่อหาเลี้ยงชีพผ่านวัยผู้ใหญ่ของคุณคุณจะอายุเท่า C ++ เป็นเกมเดียวในเมืองแอปเดสก์ท็อปเป็นบรรทัดฐานและฮาร์ดแวร์ก็ยังคงอยู่ ซอฟต์แวร์ล้าหลังอย่างมากในแง่ของความสามารถแบนด์วิดท์ / ประสิทธิภาพ

เราเคยต้องใช้เทคนิคการเขียนโปรแกรมโง่เพื่อให้สามารถอ่านไฟล์ขนาดใหญ่ (> 2G) ...
เราเคยกังวลเกี่ยวกับขนาดที่ปฏิบัติการได้ ...
เราเคยกังวลว่าโปรแกรมของเราใช้หน่วยความจำเท่าไร ...
เราทำการคำนวณเวลาตามอัลกอริธึมเทียบกับการตัดสินใจแลกเปลี่ยนพื้นที่ ...
แม้แต่แบ็คเอนด์เราก็ต้องเขียนโปรแกรม CGI ใน C หรือ C ++ เพื่ออะไรก็ตามที่จะจัดการกับหมายเลขที่เหมาะสม ของ RPS ... มันเร็วกว่าคำสั่งหลายขนาด
เราเคยทำการทดสอบเกี่ยวกับข้อดีของการทำงานระหว่าง delphi / c ++ / vb!

วันนี้มีคนน้อยมากที่ต้องกังวลเกี่ยวกับสิ่งเหล่านี้

อย่างไรก็ตามเมื่อ 10 ปีที่แล้วคุณยังกังวลเกี่ยวกับซอฟต์แวร์ของคุณที่ถูกดาวน์โหลดผ่านโมเด็ม 56kb และใช้งานบนพีซีอายุ 5 ปี ... คุณจำได้ไหมว่าพีซีที่เส็งเคร็งในปี 1996? คิดในแง่ของฮาร์ดไดรฟ์ 4GB ตัวประมวลผล 200Mhz และ RAM 128Mb ...

และเซิร์ฟเวอร์ของ 10 ปีที่แล้ว? เซิร์ฟเวอร์ "รุ่นต่อไป" ของ Dell ราคา $ 2,000 และมาพร้อมกับโปรเซสเซอร์ Pentium 2 (!) 1Ghz, 2Gb หรือ Ram และฮาร์ดไดรฟ์ 20Gb

มันเป็นเกม ballgame ที่แตกต่างกันและวิศวกร "อาวุโส" ทั้งหมดที่มีประสบการณ์ 10 ปี (พวกนั้นน่าจะตอบคำถามของคุณ) ตัดฟันของพวกเขาในสภาพแวดล้อมนั้น

— ดินแดง
แหล่งที่มา

1

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

— Blrfl

1

วนคลี่คลาย <shudder>

— ดินสีแดง

5

และทุกวันนี้เด็ก ๆ ทุกคนที่คิดแบนด์วิดธ์ซีพียูและหน่วยความจำไม่ จำกัด ก็พบว่าแอปพลิเคชั่นมือถือของพวกเขาทำงานได้ไม่ดีนัก

— gbjbaanb

9

มี 10 คำตอบอยู่ที่นี่และบางคำตอบก็ดี แต่เพราะนี่เป็นสัตว์เลี้ยงที่ฉุนสำหรับฉัน ...

การเพิ่มประสิทธิภาพก่อนวัยอันควร a) ใช้เวลาในการทำมากกว่าวิธีง่าย ๆ b) แนะนำรหัสเพิ่มเติมโดยที่วิธีแก้ปัญหาแบบง่ายจะมีขนาดเล็กลงครึ่งหนึ่งและครึ่งหนึ่งของความซับซ้อนและ c) ทำให้สิ่งต่าง ๆ อ่านง่ายกว่า อย่างไรก็ตามหากนักพัฒนามีตัวเลือกระหว่างการใช้ std :: map หรือ std :: vector และเขาเลือกคอลเลกชันที่ผิดจากความไม่รู้บริสุทธิ์สำหรับประสิทธิภาพที่ไม่ดีถ้าไม่เลวร้ายยิ่งกว่าการปรับให้เหมาะสมก่อนวัยอันควร ถ้าคุณสามารถเปลี่ยนรหัสของคุณได้เล็กน้อยในวันนี้รักษาความสามารถในการอ่านรักษาความซับซ้อนเดียวกัน แต่ทำให้มีประสิทธิภาพมากขึ้นคุณจะทำหรือไม่ หรือคุณจะเรียกมันว่า "การเพิ่มประสิทธิภาพก่อนกำหนด"? ฉันพบว่าผู้คนจำนวนมากไม่ยอมคิดเช่นนั้นไม่ทางใดก็ทางหนึ่ง

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

ในขณะที่การปรับให้เหมาะสมในช่วงต้นอาจไม่ดีฉันคิดว่ามันมีประโยชน์มากถ้าผู้เขียนโค้ดด้วยความเข้าใจว่าโค้ดนั้นจะทำอะไรและไม่เพียง แต่ไม่สนใจคำถามใด ๆ ที่ส่งผลให้สัญกรณ์ O (x) เป็น มีโค้ดมากมายที่คุณสามารถเขียนได้ในขณะนี้และด้วยความคิดเล็กน้อยเกี่ยวกับประสิทธิภาพหลีกเลี่ยงปัญหา 80% ที่เกิดขึ้น

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

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

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

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

— rong wong

6

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

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

— Jerry Coffin
แหล่งที่มา

1

+1 - หมายเหตุ: คำถาม SO ส่วนใหญ่ที่มีแท็ก "ประสิทธิภาพ" อาจเป็นส่วนหนึ่งของข้อผิดพลาดการสุ่มตัวอย่าง: P

— Billy ONeal

3

ฉันแน่ใจว่าดูเป็นจำนวนมากแช่งคำถามก่อนวัยอันควรเพิ่มประสิทธิภาพในที่นี่ ... ฉันคิดว่ามันมาจากความจริงที่ว่ามากโปรแกรมเมอร์อดิเรกเริ่มต้นด้วยความคิดของการเขียนเกมและมีคลังใหญ่ของเรื่องไร้สาระ "การเพิ่มประสิทธิภาพ" หนังสือและ เว็บไซต์ที่เกี่ยวข้องกับการพัฒนาเกมที่ใส่ความคิดที่ไม่ดีไว้ในหัวของผู้เริ่มต้น :-)

— R ..

4

เมื่อคุณจัดการกับสิ่งที่ยุ่งยากมักจะง่ายกว่าที่จะหยุดพักจากปัญหาที่ยุ่งยากและทำให้เวลาของคุณกังวลว่าคุณควรใช้i++หรือไม่++i

— Carson63000

@ Carson63000: ใช่ที่สามารถบิดเบือนตัวอย่างทั้งหมด หรือพวกเขาใช้เวลาตอบคำถามเกี่ยวกับสาเหตุที่ฉันoperator ++ไม่ได้รวบรวม

— ร

4

สองสามคำตอบอื่น ๆ พูดถึงระบบฝังตัวและฉันต้องการขยายในนี้

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

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

เพื่อที่จะใช้ตัวอย่างที่ครอบครัว STM32ของไมโครคอนโทรลเลอร์ไปจาก24 MHz, แฟลช 16 KB และ 4 กิโลไบต์ RAMสูงสุดถึง120 MHz, แฟลช 1 MB และ 128 KB RAM

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

— Steve Melnikoff
แหล่งที่มา

1

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

— Jeff

2

เหล่านี้เป็นหลักภาษาระดับต่ำเมื่อหนึ่งวิ่งเข้าไปในกรณีที่ผลการดำเนินงานทางพยาธิวิทยาที่หนึ่งรายละเอียดที่จะไม่สำคัญว่า 99% ของเวลาที่จะก่อให้เกิดคอขวดหนึ่งจริงมีโอกาสที่จะทำงานโดยตรงแก้ไขปัญหา (แตกต่างกับอื่น ๆ ส่วนใหญ่ ภาษา); แต่แน่นอนบ่อยครั้งวิธีการทำอย่างมีประสิทธิภาพมากที่สุดไม่ชัดเจนทันที ดังนั้นครึ่งหนึ่งของคำถามการเพิ่มประสิทธิภาพไมโคร / แปลกที่น่าสนใจถามที่นี่

อีกครึ่งหนึ่งมาจากผู้ที่อยากรู้ว่าพวกเขาจะเข้าไปใกล้โลหะได้อย่างไร เหล่านี้เป็นภาษาระดับต่ำเป็นหลักหลังจากทั้งหมด ...

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

+1: มูลค่าชี้ให้เห็นว่า "ประสิทธิภาพทางพยาธิวิทยา" อาจเกิดขึ้นกับทุกคนในโลกโดยไม่คำนึงถึงภาษาหรือแพลตฟอร์ม ความสามารถในการนำกลับมาใช้ใหม่ในภาษาระดับต่ำกว่าสำหรับการทดสอบและการถอดแยกชิ้นส่วนอ่านอาจให้ข้อมูลเชิงลึกเพิ่มเติมแต่ไม่ได้ให้วิธีแก้ปัญหาที่ใช้งานได้เสมอไป ตัวอย่าง: "ฉันรู้ว่าฉันสามารถทำได้ในแอสเซมบลี - แต่ต้องทำงานในสภาพแวดล้อมที่เชื่อถือได้บางส่วน!"

— ร

2

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

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

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

นี่เป็นเพียงตัวอย่างเล็ก ๆ ของปัญหาที่คุณพบ เรื่องอื่น ๆ รวมถึงฮาร์ดแวร์ของผู้ใช้เป้าหมาย คุณจะต้องกังวลเกี่ยวกับประสิทธิภาพการทำงานมากขึ้นถ้าคุณจัดการกับระบบฝังตัวแล้วถ้าผู้ใช้ของคุณมีพูด dual-core เครื่องกับกิ๊กของ ram

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

อืม .. ฉันไม่ได้ใช้เลขคณิตตัวชี้สำหรับการวนซ้ำที่เร็วกว่า - มันเป็นการคูณและเพิ่มคำสั่งต่อลูปไม่ว่าคุณจะใช้การวนซ้ำตามดัชนีหรือตัวชี้ ฉันจะใช้มันเพราะมักจะชัดเจนกว่าการทำซ้ำตามดัชนี

— Billy ONeal

เลขคณิตของตัวชี้ไม่เร็วกว่า w / e

2

โปรแกรมเมอร์สนใจทำไมมาก? มีความคิดที่โง่ประชากรหัวของพวกเขาเช่นการแก้ปัญหาประสิทธิภาพการทำงานก่อนที่พวกเขารู้ว่าพวกเขามีพวกเขาและไม่เข้าใจเมื่อพวกเขาจะมีการคาดเดา

มันเป็นเรื่องยากเพราะจากประสบการณ์ของฉันมีปัญหาเรื่องประสิทธิภาพบางอย่างที่เราควรพิจารณาล่วงหน้า ต้องใช้ประสบการณ์ในการรู้ว่าพวกเขาคืออะไร

ที่กล่าวว่าวิธีการที่ฉันใช้นั้นคล้ายกับของคุณ แต่ไม่เหมือนกัน:

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

ต่อไปนี้เป็นตัวอย่างของสิ่งที่ฉันหมายถึง

— Mike Dunlavey
แหล่งที่มา

1

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

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

โปรแกรมเมอร์ MIT รุ่นแรกไม่ได้เกิดมาเพื่อทำสิ่งที่ยอดเยี่ยม พวกเขาเริ่มลดความซับซ้อนและเพิ่มประสิทธิภาพกลไกที่มีอยู่ ความภาคภูมิใจของพวกเขาคือการทำให้ 2 + 2 ให้สี่ในสองวินาทีน้อยกว่าอัลกอริทึมที่มีอยู่ (นั่นเป็นเพียงตัวอย่างคุณได้รับแนวคิด) พวกเขาพยายามใช้ punch card น้อยลงในเครื่อง TI-83 เพื่อประสิทธิภาพ

นอกจากนี้หากคุณกำลังเขียนโปรแกรมสำหรับระบบฝังตัวแน่นอนว่าคุณต้องจับตาดูประสิทธิภาพไมโคร คุณไม่ต้องการให้มีนาฬิกาดิจิตอลช้าที่ทำเครื่องหมาย 5 นาโนวินาทีที่สองก่อนหน้านาฬิกาดิจิตอลอื่น

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

— Andy Ibanez
แหล่งที่มา

1

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

— Billy ONeal

พวกเขาไม่ได้ แต่พวกเขามีเวลามากขึ้นที่จะทำงานกับพวกเขาหากพวกเขาต้องการ

3

ฉันจะโต้แย้งตรงกันข้าม ฉันมีเวลาทำงานมากกว่า 8 ชั่วโมงต่อวัน ฉันได้รับ 1 หรือ 2 ชั่วโมงต่อวันสำหรับงานอดิเรกของฉัน

— Billy ONeal

1

ใช้อัลกอริทึม O (N2) กับ O (NlogN) ในรายการ 100 รายการ

ฉันอยู่ในสถานการณ์ที่คล้ายกันเมื่อเร็ว ๆ นี้ ฉันมีรายการมากมาย ในกรณีที่คาดไว้มีอยู่สองรายการ (!) ในรายการและแม้แต่ในกรณีที่แย่ที่สุดฉันไม่ได้คาดหวังมากกว่าสี่หรือแปด

ฉันต้องการเรียงลำดับรายการนั้น กลับกลายเป็นว่าการแทนที่std::sortด้วยเครือข่ายการเรียงลำดับ (โดยหลักแล้วจะเป็นจำนวนมากซ้อนกันif) ทำให้เวลาส่วนใหญ่หมดไป (ผมจำไม่ได้ แต่มันเป็น 10-20%) นี่เป็นข้อดีอย่างมากของการเพิ่มประสิทธิภาพขนาดเล็กและรหัสนั้นมีความสำคัญอย่างยิ่งต่อประสิทธิภาพ

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

— คอนราดรูดอล์ฟ
แหล่งที่มา

1

การใช้พลังงานสะสม

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

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

แต่เมื่อบางคนใช้หลายหมื่นคนหรือหลายล้านคนในการใช้รหัสของคุณความไร้ประสิทธิภาพทั้งหมดนั้นเพิ่มขึ้น หากเครื่องมือของคุณป้องกัน CPU ไม่ให้เข้าสู่โหมดสลีปเพียงสิบวินาทีต่อวันและผู้ใช้กว่าหนึ่งล้านคนใช้อัลกอริทึมที่ไม่มีประสิทธิภาพของคุณเพิ่งใช้งานเพิ่มขึ้น 140 kWh ^[1]ต่อวัน

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

^{[1] ฉันเพิ่งสร้างเสร็จ 10 ล้านวินาทีคูณ 50 วัตต์ ตัวเลขที่แน่นอนขึ้นอยู่กับหลายสิ่ง}

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

1

คุณควรเริ่มทันทีโดยการกล่าวคำวิเศษ "มือถือ" เมื่อเรียกใช้บนแพลตฟอร์มเดสก์ท็อปแอปพลิเคชันที่ใช้เวลา 1/100 วินาทีของเวลา CPU ในการวาดเฟรม 60 ครั้งต่อวินาทีจะเร็วพอ "; การปรับปรุงประสิทธิภาพเป็นสิบเท่าจะสร้างความแตกต่างให้กับผู้ใช้ อย่างไรก็ตามบนแพลตฟอร์มมือถือแอปพลิเคชันที่ทำงานที่การใช้งาน CPU 90% อาจทำให้แบตเตอรี่หมดเร็วกว่าการทำงานที่ 10%

— supercat

1

บางครั้งคุณมีอัลกอริทึมที่ไม่สามารถดีกว่าเวลาเชิงเส้นซึ่งยังมีความต้องการประสิทธิภาพที่ดี

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

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

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

แน่นอนว่ามันเป็นอีกกรณีหนึ่งที่ต้องพูดถึงเมื่อจำเป็นต้องปรับให้เหมาะสม (และที่สำคัญกว่านั้นคือเมื่อไม่ใช้) ไมโครหรืออัลกอริทึม แต่ในกรณีของฉันโดยเฉพาะถ้าเส้นทางการประมวลผลที่สำคัญต้องการการเพิ่มประสิทธิภาพการเพิ่มความเร็ว 10x + มักจะทำได้โดยการปรับระดับไมโครให้เหมาะสมเช่นมัลติเธรด SIMD และจัดรูปแบบหน่วยความจำใหม่และรูปแบบการเข้าถึงเพื่อปรับปรุงการอ้างอิงในท้องถิ่น มันไม่บ่อยนักที่ฉันจะพูดแทนการเรียงลำดับฟองด้วย introsort หรือ radix sort หรือการตรวจจับการชนกันของสมการกำลังสองที่ซับซ้อนด้วย BVH มากเท่ากับการหาฮอตสปอตที่พูดว่าได้รับประโยชน์จากการแยกเขตร้อน / เย็น

ตอนนี้ในกรณีของฉันสาขาของฉันมีประสิทธิภาพการทำงานที่สำคัญ (raytracing เครื่องยนต์ฟิสิกส์ ฯลฯ ) ที่ raytracer ช้า แต่ถูกต้องสมบูรณ์แบบที่ใช้เวลา 10 ชั่วโมงในการแสดงภาพมักจะถือว่าไร้ประโยชน์หรือมากกว่าหนึ่งอย่างรวดเร็วซึ่งเป็นแบบโต้ตอบอย่างสมบูรณ์ แต่ ส่งออกภาพที่น่าเกลียดที่สุดด้วยรังสีที่รั่วไปทุกหนทุกแห่งเนื่องจากไม่มีจุดตัดน้ำ / สามแยกที่กันน้ำ ความเร็วนั้นเป็นตัวชี้วัดคุณภาพหลักของซอฟต์แวร์ดังกล่าวซึ่งเป็นเนื้อหาที่มากกว่าความถูกต้องในบางจุด (เนื่องจาก "ความถูกต้อง" เป็นความคิดที่คลุมเครือกับ raytracing เนื่องจากทุกอย่างใกล้เคียงตราบใดที่มันไม่พังหรืออะไรทำนองนั้น) และในกรณีนี้ถ้าฉันไม่คิดเกี่ยวกับประสิทธิภาพล่วงหน้าฉันคิดว่าฉันต้องเปลี่ยนรหัสในระดับการออกแบบที่แพงที่สุดเพื่อจัดการกับการออกแบบที่มีประสิทธิภาพมากขึ้น ดังนั้นถ้าฉันไม่ '

การเล่นเกมเป็นอีกสาขาหนึ่งที่คล้ายกับของฉัน ไม่สำคัญว่าตรรกะของเกมของคุณจะถูกต้องหรือบำรุงรักษาและออกแบบมาอย่างยอดเยี่ยม codebase ของคุณคือถ้าเกมของคุณทำงานที่ 1 เฟรมต่อวินาทีเช่นสไลด์โชว์ ในบางฟิลด์การขาดความเร็วอาจทำให้แอปพลิเคชันไร้ประโยชน์ต่อผู้ใช้ ซึ่งแตกต่างจากเกมไม่มีตัวชี้วัด "ดีพอ" ในพื้นที่เช่น raytracing ผู้ใช้ต้องการความเร็วมากขึ้นและการแข่งขันในอุตสาหกรรมนั้นส่วนใหญ่จะแสวงหาวิธีแก้ปัญหาที่รวดเร็วกว่า มันจะไม่ดีพอจนกว่าจะถึงเวลาจริงซึ่งเกมจุดนั้นจะใช้เครื่องมือสะกดรอยตามเส้นทาง และก็อาจจะไม่ดีพอสำหรับ VFX เนื่องจากศิลปินอาจต้องการโหลดรูปหลายเหลี่ยมหลายพันล้านและมีการจำลองอนุภาคด้วยการชนกันของอนุภาคนับพันล้านที่ 30+ FPS

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

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

0

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

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

0

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

— Nemanja Trifunovic
แหล่งที่มา

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

— K.Steff

0

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

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

เป็นเรื่องดีที่แสดงความรู้ทักษะและกลอุบายของคุณและนำสิ่งที่คุณเรียนรู้มาใช้ซ้ำ มันทำให้คุณรู้สึกมีค่าและเวลาใช้ในการเรียนรู้ว่ามันคุ้มค่า

บางครั้งในชีวิตของฉันฉันได้เรียนรู้การเพิ่มคำนำหน้าจะเร็วขึ้น

for (int i = 0; i < MAX; ++i)

... มากกว่าการเพิ่มขึ้นของ postfix:

for (int i = 0; i < MAX; i++)

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

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

— ไม่ทราบผู้ใช้
แหล่งที่มา

0

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

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

หากต้องการขอบเขตประสิทธิภาพเป็นความต้องการเสมอ หากคุณสามารถตีได้โดยไม่ต้องคิดถึงมันคุณจะได้รับการพิสูจน์ว่าไม่ได้คิด

โดยส่วนตัวแล้วฉันมักจะได้แรงหนุนจากการแสดงเมื่อการทดสอบของฉันใช้เวลานานในการผ่าน ฉันใจร้อนเกินกว่าจะรอ 5 นาทีในขณะที่ชุดทดสอบผ่านไป แต่ก็มักจะแก้ไขได้โดยเล่นซอกับการทดสอบ

คำถามของฉันคือเหตุใดโปรแกรมเมอร์จำนวนมากจึงสนใจ? มันเป็นปัญหาสำหรับนักพัฒนาส่วนใหญ่จริงหรือ

มีโปรแกรมเมอร์จำนวนมากที่พิสูจน์ว่าพวกเขาสนใจมากแค่ไหน มีคนจำนวนมากที่ไม่ได้เป็น พูดคุยเกี่ยวกับคนที่ไม่ได้

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

Knuth ถูกต้อง: การเพิ่มประสิทธิภาพก่อนวัยอันควรเป็นรากฐานของความชั่วร้ายทั้งหมด แต่เมื่อมันทำงานขั้นตอนต่อไปคืออะไร? เร็วใช่มั้ย NO! ขั้นตอนต่อไปสามารถอ่านได้ สามารถอ่านได้เป็นขั้นตอนแรกถัดไปกลางและสุดท้าย ผู้คนจำนวนมากที่ฉันพบว่าการเพิ่มประสิทธิภาพการทำงานที่ไม่จำเป็นนั้นกำลังทำให้อ่านง่ายขึ้นใต้รถบัส

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

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

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

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

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

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