ทำไมการเพิ่มประสิทธิภาพเร็วเกินไปจึงไม่ดี

หลังจากมองไปที่การเพิ่มประสิทธิภาพเล็กน้อยฉันได้ค้นพบ (ดูเหมือนว่าทุกหนทุกแห่ง) ว่ามันเป็นบาปที่ได้รับการยอมรับในระดับสากลในการเพิ่มประสิทธิภาพเกมเร็วเกินไป

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

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

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

บทนำ:

มีการคัดค้านเล็กน้อยในความคิดเห็นและฉันคิดว่าพวกเขาส่วนใหญ่มาจากความเข้าใจผิดของสิ่งที่เราหมายถึงเมื่อเราพูดว่า "การเพิ่มประสิทธิภาพก่อนวัยอันควร" - ดังนั้นฉันต้องการเพิ่มความกระจ่างเล็กน้อย

"อย่าเพิ่มประสิทธิภาพก่อนเวลาอันควร" ไม่ได้หมายความว่า "เขียนโค้ดที่คุณรู้ว่าไม่ดีเพราะ Knuth บอกว่าคุณไม่ได้รับอนุญาตให้ล้างข้อมูลจนกว่าจะสิ้นสุด"

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

ซึ่งหมายความว่าเมื่อมีข้อสงสัยเราควร:

• ชอบรหัสที่เขียนง่ายเข้าใจง่ายและปรับเปลี่ยนได้ง่ายสำหรับผู้เริ่ม

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

การปรับให้เหมาะสมก่อนวัยอันควรไม่ใช่ :

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

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

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

การเพิ่มประสิทธิภาพทุกประเภทนั้นมีความชอบธรรมและโดยทั่วไปจะไม่ระบุว่า "ก่อนกำหนด" (เว้นแต่คุณจะลงไปที่โพรงกระต่ายโดยใช้การหาตำแหน่งที่ทันสมัยสำหรับแผนที่กระดานหมากรุกขนาด 8x8 ของคุณ ... )

ดังนั้นตอนนี้เมื่อล้างข้อมูลไปแล้วทำไมเราอาจพบว่านโยบายนี้มีประโยชน์ในเกมโดยเฉพาะ:

โดยเฉพาะใน gamedev ความเร็วการทำซ้ำเป็นสิ่งที่มีค่าที่สุด เรามักจะนำไปใช้และนำความคิดกลับมาใช้ใหม่มากกว่าที่จะมาพร้อมกับเกมที่เสร็จสิ้นแล้วพยายาม "ค้นหาความสนุก"

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

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

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

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

เพื่อยกตัวอย่างที่น่าทึ่ง: หากเกมของคุณมี GPU (ไม่ใช่เรื่องแปลก) ดังนั้นทุกครั้งที่ใช้การไฮเปอร์ - ออปติไมซ์และเธรดการทำงานของ CPU อาจไม่ได้รับประโยชน์ที่จับต้องได้เลย ชั่วโมง dev ทั้งหมดเหล่านั้นอาจถูกใช้ไปกับการใช้งานและการขัดเกลาคุณสมบัติการเล่นเกมแทนเพื่อประสบการณ์การเล่นที่ดีขึ้น

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

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

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

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

สำหรับฉันแล้วนี่คือจุดเริ่มต้นของคำถาม

เมื่อสร้างการออกแบบดั้งเดิมของคุณคุณควรพยายามออกแบบให้มีประสิทธิภาพ - ในระดับสูงสุด นี่เป็นการปรับให้เหมาะสมน้อยลงและมีโครงสร้างมากขึ้น

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

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

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

ตัวเลือก:

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

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

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

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

TL; DR:

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

จากนั้นคุณสามารถเปลี่ยนกลไกภายในแต่ละโมดูลโดยไม่ต้องปรับโครงสร้าง codebase ทั้งหมดเมื่อคุณต้องการปรับให้เหมาะสม

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

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

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

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

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

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

ทุกอย่างที่เกี่ยวกับเข็มขัดนั้นจะต้องถูกจัดแจงใหม่เพื่อให้สายพานนั้นได้รับการปรับให้เหมาะสม และเข็มขัดจำเป็นต้องได้รับการปรับให้เหมาะสมเพราะคุณต้องการสายพานจำนวนมากสำหรับโรงงานขนาดใหญ่และโรงงานขนาดใหญ่เป็นแหล่งท่องเที่ยวหนึ่งของเกม ท้ายที่สุดถ้าคุณไม่มีโรงงานขนาดใหญ่ทำไมต้องมีโลกที่ไม่มีที่สิ้นสุด ตลกที่คุณควรถาม - เวอร์ชันก่อนหน้าไม่ได้ :) เกมนี้ได้รับการทำใหม่และปรับรูปแบบใหม่หลาย ๆ ครั้งเพื่อให้ได้มาซึ่งตอนนี้ - รวมทั้งรีเมคที่สมบูรณ์แบบ 100% เมื่อพวกเขารู้ว่า Java ไม่ใช่หนทาง เกมแบบนี้และเปลี่ยนเป็น C ++ และมันใช้งานได้ดีสำหรับ Factorio (แม้ว่ามันจะยังคงเป็นสิ่งที่ดีที่มันไม่ได้รับการปรับปรุงให้ดีขึ้นจากการไปโดยเฉพาะอย่างยิ่งเนื่องจากนี่เป็นโครงการงานอดิเรกซึ่งอาจจะล้มเหลวเพียงเพราะขาดความสนใจ)

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

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

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

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

ขำขันฉันในขณะที่ฉันพยายามที่จะอธิบายอย่างละเอียดเกี่ยวกับมุมมองของฉันด้วยความช่วยเหลือของ polyominoes

สมมติว่าเรามีขอบเขตคงที่ที่กำหนดโดยกรอบงานหรือเอนจิ้นที่เรากำลังทำงานด้วย

จากนั้นเราจะสร้างเลเยอร์ / โมดูลแรกของเกมต่อไป

ก้าวต่อไปเราสร้างเลเยอร์ / โมดูลที่สอง

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

สมบูรณ์แบบตอนนี้แอปพลิเคชันใช้ทรัพยากรที่มีให้เราอย่างเต็มที่แอปพลิเคชันดีกว่าดีใช่มั้ย

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

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

ดังนั้นเราจึงรวบรวมทั้งหมด ...

อืมคุณเห็นสิ่งที่เกิดขึ้นไหม

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

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

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

อย่างไรก็ตามหากเราเลือกที่จะรอด้วยการกระตุ้นเพื่อเพิ่มประสิทธิภาพทันทีที่เราจะได้สิ่งที่เป็นเช่นนี้:

และตอนนี้ถ้าเราทำการปรับให้เหมาะสม ณ จุดนี้เราจะได้รับสิ่งที่น่าพึงพอใจที่จะดู

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

เงิน

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

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

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

^{* คำตอบอื่น ๆ ให้ความสำคัญกับส่วน 'เวลา' เป็นอย่างดี}

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

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

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

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

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

พื้นที่ที่แท้จริงของการแก้ปัญหานั้นใหญ่กว่าที่เราคาดไว้ตั้งแต่แรกเพราะเราไม่มีความรู้ที่สมบูรณ์แบบของระบบที่ซับซ้อนมาก

ทำให้มันทำงานก่อน แล้วขันให้แน่น

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

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

โดยทั่วไปเพิ่มประสิทธิภาพเฉพาะในกรณีที่คุณไม่สามารถทำงานกับการสร้างการพัฒนาได้ในขณะนี้ เช่นถ้าคุณกำลังสร้างและลบวัตถุนับล้านครั้ง 60 ครั้งต่อวินาที

ดังนั้นฉันจะบอกว่ามันดีในแง่ของประสบการณ์การเรียนรู้

การเพิ่มประสิทธิภาพมุ่งเน้นไปที่การทำให้คอมพิวเตอร์ทำงานได้ดีที่สุดในรหัสในขณะที่การพัฒนาต้องทำให้โปรแกรมเมอร์ทำงานได้ดีที่สุดในรหัส

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

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

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

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

สิ่งสุดท้ายที่ฉันต้องการเพิ่มคือภายหลังแม้ว่าคุณไม่ต้องการสร้างเกมอีกต่อไปคุณมีอัลกอริทึม A * ที่ปรับให้เหมาะสมซึ่งคุณสามารถใช้สำหรับเกมถัดไปของคุณ สามารถนำมาใช้ ตัวอย่างเช่นเกมหลายเกมมีรายการสินค้าการสร้างเส้นทางการสร้างขั้นตอนการโต้ตอบระหว่าง npc ระบบการต่อสู้ AI การโต้ตอบส่วนต่อประสานการจัดการอินพุต ตอนนี้คุณควรถามตัวเองว่า - "ฉันเขียนองค์ประกอบเหล่านั้นอีกครั้งกี่ครั้งตั้งแต่ต้น?" พวกเขาเป็น 70-80% ของเกม คุณต้องการเขียนใหม่ตลอดเวลาหรือไม่? และถ้าพวกเขาไม่ได้เพิ่มประสิทธิภาพล่ะ?