การเพิ่มประสิทธิภาพไม่ได้เกิดก่อนกำหนดและเมื่อใดจึงไม่ชั่ว

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

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

เมื่อไหร่ที่มันไม่เจ็บปวด? ไม่ใช่ความชั่วร้าย "การนำสิ่งนี้ไปใช้ในฐานะที่เป็น Foo หรือ Bar จะใช้งานได้มาก แต่ในทางทฤษฎีแล้ว Bar ควรมีประสิทธิภาพมากกว่านี้กันเถอะ"

เมื่อคุณหลีกเลี่ยงอัลกอริทึมเส็งเคร็งที่จะขยายขนาดมหึมา? ไม่ใช่ความชั่วร้าย "หัวหน้าฝ่ายเทคโนโลยีของเรากล่าวว่าอัลกอริธึมการเลือกพา ธ ที่เรานำเสนอนั้นทำงานในช่วงแฟคทอเรียล; ฉันไม่แน่ใจว่ามันหมายถึงอะไร แต่เธอแนะนำให้เราใช้ seppuku เพื่อพิจารณา

ความชั่วร้ายมาจากการใช้เวลาและปัญหาการแก้ปัญหาพลังงานที่คุณไม่รู้ว่ามีอยู่จริง เมื่อมีปัญหาเกิดขึ้นจริงหรือเมื่อปัญหา psudo phantom อาจแก้ไขได้ในราคาถูกความชั่วก็จะหายไป

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

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

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

การเพิ่มประสิทธิภาพแบบใดที่ไม่ได้เกิดก่อนกำหนด

ชนิดที่มาจากปัญหาที่ทราบ

การเพิ่มประสิทธิภาพไม่ได้เกิดก่อนกำหนดและเมื่อใดจึงไม่ชั่ว

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

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

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

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

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

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

คุณควรเลือกโซลูชันที่ "ดีพอ" ในทุกกรณีตามประสบการณ์ของคุณ

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

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

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

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

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

ขั้นตอนที่ 2 และ 3 อธิบายการปรับให้เหมาะสมที่ไม่ใช่ก่อนวัย

1. ทำให้มันใช้งานได้
2. ทดสอบ. ไม่เร็วพอหรือ ข้อมูลส่วนตัวของมัน
3. ใช้ข้อมูลจากขั้นตอนที่ 2 เพิ่มประสิทธิภาพส่วนที่ช้าที่สุดของรหัส

ไม่ใช่การเพิ่มประสิทธิภาพเมื่อเลือกสิ่งที่ยากที่จะเปลี่ยนแปลงเช่นแพลตฟอร์มฮาร์ดแวร์

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

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

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

ใครบางคนพูดว่า: ทำให้มันถูกต้องก่อนแล้วทำให้มันเร็ว พวกเขาพูดถูก

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

ดังนั้นการถกเถียงโง่ ๆ เหล่านี้ยังคงดำเนินต่อไป :)

** อีกสิ่งที่พวกเขาพูดคือคุณไม่ต้องกังวลเกี่ยวกับเรื่องนี้อีกต่อไปเพราะคอมไพเลอร์ดีมากและเครื่องจักรก็เร็วมากในปัจจุบัน (KIWI - Kill It With Iron.) ไม่มีฮาร์ดแวร์เอ็กซ์โพเนนเชียลหรือการเร่งความเร็วระบบ (ทำโดยวิศวกรที่ทำงานอย่างชาญฉลาดมาก ๆ ) ที่สามารถชดเชยการชะลอตัวของซอฟต์แวร์เอ็กซ์โปเนนเชียล (ทำโดยโปรแกรมเมอร์ที่คิดแบบนี้)

เมื่อความต้องการหรือตลาดขอเฉพาะมัน

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

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

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

ตัวอย่างโลกแห่งความจริง

• ถ้าการเรียงลำดับแบบบับเบิลของฉันใช้เวลา 20 มิลลิวินาทีในการทำงานการเพิ่มประสิทธิภาพให้เป็น Quicksort ขนาด 1 มิลลิวินาทีจะไม่เพิ่มประสิทธิภาพของยูทิลิตี้โดยรวมในลักษณะที่มีความหมายแม้จะเพิ่มประสิทธิภาพ 2000% ก็ตาม

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

การเพิ่มประสิทธิภาพแบบใดที่ไม่ได้กำหนดไว้ล่วงหน้า?

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

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

(เช่นไม่ใช่ - "ฉันคิดว่ารหัสนี้ดูเหมือนว่าจะช้าฉันจะเปลี่ยน X เป็น Y แทนและจะเร็วขึ้น")

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

"การเพิ่มประสิทธิภาพก่อนวัยอันควรเป็นรากฐานของความชั่วร้ายทั้งหมด" เป็นสิ่งที่เราเกือบทุกคนเคยได้ยิน / อ่าน

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

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

โปรดทราบว่า Knuth พูดคุยเกี่ยวกับความเร็วของการดำเนินการในรันไทม์โดยเฉพาะ

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

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

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

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

• คอขวดซึ่งสามารถมองเห็นได้ด้วยตาเปล่าและสามารถหลีกเลี่ยงได้ก่อนที่จะถูกนำมาใช้เช่นจำนวน O (N ^ 2) ของ roundtrips ไปยังฐานข้อมูลที่มี N ขนาดใหญ่ที่มีทางเลือก O (1) อยู่

สิ่งต่อไปนี้จะไม่เกี่ยวข้องกับความเร็วของการทำงานแบบรันไทม์:

• การออกแบบล่วงหน้าอย่างรอบคอบ

• การพิมพ์แบบคงที่ (!)

• ฯลฯ / ความพยายามทางจิตทุกรูปแบบ