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

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

เป็นสิ่งสำคัญที่ต้องคำนึงถึงคำพูดทั้งหมด:

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

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

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

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

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

• การปรับแต่งสถาปัตยกรรมให้เหมาะสม (โครงสร้างแอปพลิเคชัน, วิธีที่ส่วนประกอบและเลเยอร์)
• การเพิ่มประสิทธิภาพการไหลของข้อมูล (ภายในและภายนอกแอปพลิเคชัน)

การเพิ่มประสิทธิภาพวงจรการพัฒนาระดับกลางบางอย่าง:

• โครงสร้างข้อมูลแนะนำโครงสร้างข้อมูลใหม่ที่มีประสิทธิภาพดีขึ้นหรือลดค่าใช้จ่ายหากจำเป็น
• อัลกอริทึม (ตอนนี้เป็นเวลาที่ดีที่จะเริ่มตัดสินใจระหว่าง quicksort3 และ heapsort ;-))

การเพิ่มประสิทธิภาพรอบการพัฒนาขั้นสุดท้าย

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

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

หากผลการดำเนินงานเป็นกังวล (และควรจะเป็น) มักจะคิดว่าใหญ่ การแสดงเป็นภาพที่ใหญ่ขึ้นและไม่เกี่ยวกับสิ่งต่าง ๆ เช่น: ฉันควรใช้intหรือยาว ? Go for Top Downเมื่อทำงานกับประสิทธิภาพการทำงานแทนการด้านล่างขึ้น

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

ฉันเชื่อว่าเป็นจริงในกรณีนี้และเป็นจริงในกรณีทั่วไปเช่นกัน

การเพิ่มประสิทธิภาพคือ "ความชั่วร้าย" ถ้ามันทำให้:

• รหัสที่ชัดเจนน้อยลง
• รหัสมากขึ้นอย่างมีนัยสำคัญ
• รหัสที่ปลอดภัยน้อยกว่า
• เสียเวลาโปรแกรมเมอร์

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

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

นี่คือคำพูดที่ใหญ่กว่า (จากหน้า 8 ของ pdf, หน้า 268 ในต้นฉบับ):

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

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

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

อีกเล็กน้อยที่ดีจากหน้าก่อนหน้า:

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

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

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

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

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

• สตริงนั้นมีราคาสูงกว่าตัวเลข
• ภาษาแบบไดนามิกนั้นช้ากว่าภาษาที่พิมพ์แบบคงที่
• ข้อดีของรายการ array / vector บนรายการที่เชื่อมโยงและในทางกลับกัน
• เมื่อใดควรใช้ hashtable เมื่อใดควรใช้แผนที่ที่เรียงลำดับและเมื่อใดควรใช้ heap
• (ถ้าทำงานร่วมกับอุปกรณ์พกพา) "double" และ "int" มีประสิทธิภาพการทำงานที่คล้ายคลึงกันบนเดสก์ท็อป (FP อาจเร็วกว่า) แต่ "double" อาจช้ากว่าร้อยเท่าบนอุปกรณ์พกพาระดับต่ำที่ไม่มี FPU
• การถ่ายโอนข้อมูลผ่านอินเทอร์เน็ตนั้นช้ากว่าการเข้าถึง HDD, HDD นั้นช้ากว่า RAM อย่างมากมาย RAM ช้ากว่าแคชและรีจิสเตอร์ L1 มากและการดำเนินการทางอินเทอร์เน็ตอาจบล็อกอย่างไม่มีกำหนด (และล้มเหลวได้ตลอดเวลา)

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

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

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

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

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

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

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

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

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

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

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

ดูที่ Bochs มันช้าเหมือนนรก มันจะเร็วขึ้นไหม? อาจจะ แต่ในช่วงไม่กี่เปอร์เซ็นต์เท่านั้น จะไม่มีวันได้รับประสิทธิภาพเทียบเท่ากับซอฟต์แวร์การจำลองเสมือนเช่น VMWare หรือ VBox หรือแม้แต่ QEMU เพราะมันช้าตามการออกแบบ!

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

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

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

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

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

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

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

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

ฉันเชื่อว่านี่เป็นสิ่งที่ Mike Cohn เรียกว่า 'การชุบทองคำ' - นั่นคือการใช้เวลากับสิ่งต่าง ๆ ซึ่งอาจดี แต่ไม่จำเป็น

เขาแนะนำกับมัน

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

เนื่องจากไม่มีปัญหาในการทำความเข้าใจรหัสดังนั้นกรณีนี้จึงถือเป็นข้อยกเว้น

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

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

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

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

จากมุมมองที่แตกต่างกันมันเป็นประสบการณ์ของฉันที่โปรแกรมเมอร์ / นักพัฒนาส่วนใหญ่ไม่ได้วางแผนเพื่อความสำเร็จและ "ต้นแบบ" เกือบจะกลายเป็นรีลีส 1.0 เสมอ ฉันมีประสบการณ์โดยตรงกับผลิตภัณฑ์ต้นฉบับ 4 แบบแยกกันซึ่ง front-end ที่ดีงามและมีประสิทธิภาพสูง (โดยทั่วไปคือ UI) ส่งผลให้ผู้ใช้ยอมรับอย่างกว้างขวางและกระตือรือร้น ในแต่ละผลิตภัณฑ์ปัญหาด้านประสิทธิภาพเริ่มคืบคลานเข้ามาภายในระยะเวลาอันสั้น (1 ถึง 2 ปี) โดยเฉพาะลูกค้าที่มีขนาดใหญ่และมีความต้องการมากขึ้นเริ่มนำผลิตภัณฑ์มาใช้ ในไม่ช้าประสิทธิภาพการทำงานจะครอบงำรายการปัญหาแม้ว่าการพัฒนาคุณสมบัติใหม่จะจัดการรายการที่มีความสำคัญของการจัดการ ลูกค้าผิดหวังมากขึ้นเรื่อย ๆ เนื่องจากแต่ละรุ่นเพิ่มคุณสมบัติใหม่ซึ่งฟังดูยอดเยี่ยม แต่แทบจะไม่สามารถเข้าถึงได้เนื่องจากปัญหาด้านประสิทธิภาพ

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

การสาธิตลูกค้าของคุณอาจดูดีและมีประสิทธิภาพบนแล็ปท็อปของคุณด้วย XML DOMs, SQL Express และข้อมูลแคชที่ฝั่งไคลเอ็นต์มากมาย ระบบการผลิตอาจจะเกิดปัญหาการเบิร์นหากคุณประสบความสำเร็จ

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

เมื่อหนึ่งสุภาษิตซ้ำเป็นข้อแก้ตัวสำหรับการไม่เขียนโค้ดที่มีประสิทธิภาพ (C ++, VB, T-SQL หรืออื่น ๆ ) หรือสำหรับการออกแบบที่เก็บข้อมูลไม่ถูกต้องหรือไม่พิจารณาสถาปัตยกรรมการทำงานสุทธิจากนั้น IMO พวกเขาเพียงแสดง ความเข้าใจตื้นเขินมากเกี่ยวกับลักษณะที่แท้จริงของงานของเรา รังสี

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

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

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

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

• มุมมองที่ปรากฏขึ้นหนึ่งมุมมองเพื่อรองรับหน้าจอการค้นหา

• ตารางบำรุงรักษาทริกเกอร์หนึ่งตารางเพื่อสนับสนุนหน้าจอค้นหาอื่นที่ไม่สามารถทำได้ด้วยมุมมองที่ปรากฏ

• หนึ่งตารางการรายงานที่ผิดปกติ (มีอยู่เพราะเราต้องทำรายงานปริมาณงานบางอย่างเมื่อโครงการคลังข้อมูลบรรจุกระป๋อง)

• หนึ่งตารางที่รักษาทริกเกอร์สำหรับอินเทอร์เฟซที่ต้องค้นหาเหตุการณ์ล่าสุดจำนวนมากภายในระบบ

นี่คือโครงการ J2EE ที่ใหญ่ที่สุดในออสเตรเลียเวลามากกว่านักพัฒนากว่า 100 ปีและมีรายการ 4 รายการในฐานข้อมูลซึ่งหนึ่งในนั้นไม่ได้อยู่ในนั้นเลย

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

• คุณลงทุนเวลามากขึ้นในระหว่างการพัฒนา
• คุณลงทุนเวลามากขึ้นในการทดสอบ
• คุณลงทุนเวลามากขึ้นในการแก้ไขข้อบกพร่องที่ไม่ได้อยู่ที่นั่น

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

ส่วนใหญ่ของผู้ที่ปฏิบัติตาม "PMO" (คำพูดบางส่วนกล่าวคือ) กล่าวว่าการปรับให้เหมาะสมต้องอยู่บนพื้นฐานของการวัดและการวัดไม่สามารถทำได้จนกว่าจะถึงจุดสิ้นสุด

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

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

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

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

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

ตรวจสอบชิ้นส่วนที่ยอดเยี่ยมนี้เกี่ยวกับสิ่งที่สำนักงานปลัดฯ อาจจะหรือไม่ได้หมายความ