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

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

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

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

นั่นเป็นเกียรติของคุณ แต่หยุดเถอะ

หยุด!

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

ยังไง? มาสำรองข้อมูลกัน

ก่อนอื่นอะไร คือ การเพิ่มประสิทธิภาพรหัส?

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

ในทางปฏิบัติบางครั้งเราตั้งค่าเริ่มต้นเป็นคำจำกัดความอื่น: การเขียนโค้ดน้อยลง

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

ดังนั้นการเพิ่มประสิทธิภาพโค้ดจึงเป็นคำที่คลุมเครือเล็กน้อย ก่อนที่เราจะพิจารณาวิธีการอื่น ๆ เพื่อเพิ่มประสิทธิภาพโค้ดซึ่งเราจะอธิบายด้านล่างนี้

เริ่มต้นด้วยการฟังคำแนะนำของปราชญ์ขณะที่เราสำรวจด้วยกัน แจ็คสัน กฎการเพิ่มประสิทธิภาพโค้ดที่มีชื่อเสียง:

1. อย่าทำ
2. (สำหรับผู้เชี่ยวชาญเท่านั้น!) อย่าทำ ยัง .

1. อย่าทำอย่างนั้น: การแสดงความสมบูรณ์แบบ

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

ฉันแค่ทำให้เท้าเปียกในโลกที่แสนวิเศษมีเค้กและกินมันเกินไปของ SQL ปัญหาคือจากนั้นฉันก็เหยียบเค้ก ...

รอ. ให้ฉันกลับออกไปจากซากรถของอุปมาที่เพิ่งสร้างและอธิบาย

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

ว่าทุกอย่างหยุดชะงักการพัฒนา - และ ประสิทธิภาพที่ชาญฉลาดเพราะ ... คุณเดาถูกแล้วการเพิ่มประสิทธิภาพ

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

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

โอ้มนุษย์ ฉันเพิ่งปรับความยืดหยุ่นนั้นให้เหมาะสม เหี้ยมาก .

มากเกินไปในความเป็นจริง ตอนนี้ฉันมีปัญหาใหม่: ให้ relationship_type โดยธรรมชาติจะไม่สมเหตุสมผลระหว่างการรวมกันของแถว แม้ว่ามันอาจจะทำให้รู้สึกว่า a person มี employed by ความสัมพันธ์กับ company ที่ไม่สามารถเทียบเท่าความหมายได้กับความสัมพันธ์ระหว่างพูดสอง document s

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

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

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

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

ถูกต้องแล้ว“ โอ้”

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

ปรับนิสัยของคุณให้เหมาะสมไม่ใช่จรรยาบรรณของคุณ

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

1. ความปลอดภัย
2. ความเสถียรของรันไทม์
3. ความชัดเจนและสไตล์
4. ประสิทธิภาพการเข้ารหัส
5. ทดสอบประสิทธิผล
6. การทำโปรไฟล์
7. ชุดเครื่องมือของคุณ / DE
8. แห้ง (อย่าทำซ้ำตัวเอง)

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

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

ตัวอย่างเช่นเกี่ยวกับ DRY: ในงานหนึ่งที่ฉันมีฉันได้รับโค้ดเบสที่มีคำสั่งซ้ำซ้อนอย่างน้อย 80% เนื่องจากผู้เขียนเห็นได้ชัดว่าไม่รู้ว่าจะเขียนฟังก์ชันอย่างไรและเมื่อใด อีก 20% ของรหัสนั้นคล้ายกันอย่างสับสน

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

เห็นได้ชัดว่าจำเป็นต้องปรับโครงสร้างใหม่เพื่อความมีสติของตัวเอง (มูลค่าสูง) และสำหรับนักพัฒนาในอนาคต แต่เนื่องจากฉันยังใหม่กับ codebase ฉันจึงเขียนการทดสอบก่อนเพื่อที่ฉันจะได้แน่ใจว่าการปรับโครงสร้างของฉันไม่ได้ทำให้เกิดการถอยหลังใด ๆ ในความเป็นจริงพวกเขาทำอย่างนั้น: ฉันจับบั๊กสองตัวระหว่างทางที่ฉันไม่ได้สังเกตเห็นในบรรดา gobbledygook ที่สร้างสคริปต์ออกมา

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

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

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

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

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

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

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

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

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

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

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

แล้วกฎข้อที่สองล่ะ? เมื่อไหร่ เราสามารถเพิ่มประสิทธิภาพได้จริงหรือ

2. อย่าทำ ยัง : มีคนทำสิ่งนี้แล้ว

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

มาดูกัน อย่าทำเลย ก้าวไปอีกขั้น: ยังไม่ได้เขียนโค้ด .

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

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

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

(สิ่งที่ตรงกันข้ามกับรูปแบบทั่วไปนี้คือ Java Calendar API แบบเก่า แต่ ได้รับการแก้ไขแล้ว .)

ตรวจสอบไลบรารีมาตรฐานของคุณตรวจสอบระบบนิเวศของ Framework ของคุณตรวจสอบ FOSS ที่แก้ปัญหาของคุณได้แล้ว

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

ตัวอย่างเช่นเมื่อเร็ว ๆ นี้ฉันกำลังเตรียมวิเคราะห์กลยุทธ์ AI สำหรับเกมกระดาน ฉันตื่นขึ้นมาในเช้าวันหนึ่งโดยตระหนักว่าการวิเคราะห์ที่ฉันวางแผนไว้สามารถทำตามลำดับความสำคัญได้อย่างมีประสิทธิภาพมากขึ้นหากฉันใช้แนวคิดแบบ Combinatorics ที่ฉันจำได้ ไม่ได้สนใจที่จะหาอัลกอริทึมสำหรับแนวคิดนี้ด้วยตัวเองในเวลานี้ฉันได้ก้าวไปข้างหน้าแล้วโดยรู้ชื่อที่ถูกต้องในการค้นหา อย่างไรก็ตามฉันพบว่าหลังจากใช้เวลาค้นคว้าประมาณ 50 นาทีและลองใช้โค้ดเบื้องต้นฉันไม่สามารถเปลี่ยนโค้ดหลอกครึ่งสำเร็จรูปที่ฉันพบให้เป็นการใช้งานที่ถูกต้องได้ (คุณเชื่อไหมว่ามีบล็อกโพสต์อยู่ที่นั่นซึ่งผู้เขียนสันนิษฐานว่าเอาต์พุตอัลกอริทึมไม่ถูกต้องใช้อัลกอริทึมไม่ถูกต้องเพื่อให้ตรงกับสมมติฐานผู้แสดงความคิดเห็นชี้ให้เห็นสิ่งนี้และหลายปีต่อมาก็ยังไม่ได้รับการแก้ไข) ณ จุดนั้นน้ำชายามเช้าของฉัน เตะเข้าและฉันค้นหา [name of concept] [my programming language] 30 วินาทีต่อมาฉันได้แก้ไขโค้ดจาก GitHub แล้วและกำลังดำเนินการต่อในสิ่งที่ฉันต้องการจะทำจริงๆ เพียงแค่ระบุเฉพาะและรวมถึงภาษาแทนที่จะคิดว่าฉันต้องใช้มันเองก็หมายถึงทุกอย่าง

ถึงเวลาออกแบบโครงสร้างข้อมูลของคุณและใช้อัลกอริทึมของคุณ

…อีกครั้งอย่าเล่น รหัสกอล์ฟ . จัดลำดับความสำคัญของความถูกต้องและชัดเจนในโครงการจริง

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

ไม่มีปัญหา. คำแนะนำนั้นง่ายมากตามลำดับนี้:

1. ออกแบบเพื่อให้ง่ายต่อการอธิบายกับโปรแกรมเมอร์มือใหม่
2. เขียนแบบทดสอบที่เหมาะกับความคาดหวังที่เกิดจากการออกแบบนั้น
3. เขียนโค้ดของคุณเพื่อให้โปรแกรมเมอร์มือใหม่สามารถรวบรวมการออกแบบจากมันได้อย่างง่ายดาย

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

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

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

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

ตัวอย่าง ECMAScript

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

const zeroPhrase = 'No more'; const wallPhrase = ' on the wall'; const standardizeNumber = number => { if (number === 0) { return zeroPhrase; } return '' + number; } const bottlePhrase = number => { const possibleS = (number === 1) ? '' : 's'; return standardizeNumber(number) + ' bottle' + possibleS + ' of beer'; } export default class Beer { static verse(number) { const nextNumber = (number === 0) ? 99 : (number - 1); const thisBottlePhrase = bottlePhrase(number); const nextBottlePhrase = bottlePhrase(nextNumber); let phrase = thisBottlePhrase + wallPhrase + ', ' + thisBottlePhrase.toLowerCase() + '. '; if (number === 0) { phrase += 'Go to the store and buy some more'; } else { const bottleReference = (number === 1) ? 'it' : 'one'; phrase += 'Take ' + bottleReference + ' down and pass it around'; } return phrase + ', ' + nextBottlePhrase.toLowerCase() + wallPhrase + '. '; } static sing(start = 99, end = 0) { return Array.from(Array(start - end + 1).keys()).map(offset => { return this.verse(start - offset); }).join(' '); } }

แทบจะไม่มีการทำซ้ำสตริงเลย! ด้วยการเขียนด้วยวิธีนี้ฉันได้ใช้รูปแบบการบีบอัดข้อความสำหรับเพลงเบียร์ด้วยตนเอง (แต่ เท่านั้น สำหรับเพลงเบียร์) ประโยชน์คืออะไรกันแน่? สมมติว่าคุณอยากร้องเพลงเกี่ยวกับการดื่มเบียร์จากกระป๋องแทนที่จะดื่มขวด ฉันสามารถทำได้โดยการเปลี่ยนแปลง หนึ่งอินสแตนซ์เดียว ของ bottle ถึง can.

ดี!

…ขวา?

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

ในขณะเดียวกันตัวแปรของฉันจะถูกตั้งชื่อแปลก ๆ ในภายหลังโดยมีสิ่งต่างๆเช่น bottlePhrase ไม่มีอะไรเกี่ยวข้องกับ ขวด เลย. วิธีเดียวที่จะหลีกเลี่ยงปัญหานี้ได้คือการคาดการณ์ประเภทของการเปลี่ยนแปลงที่จะเกิดขึ้นและใช้คำทั่วไปเช่น vessel หรือ container แทนที่ bottle ในชื่อตัวแปรของฉัน

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

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

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

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

แต่เรายังไม่ได้เพิ่มประสิทธิภาพ!

ตอนนี้อัลกอริทึมของคุณได้รับการใช้งานและคุณได้พิสูจน์แล้วว่าผลลัพธ์นั้นถูกต้องขอแสดงความยินดี! คุณมีพื้นฐาน!

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

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

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

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

บางทีคุณอาจพบว่าทุกอย่างเรียบร้อยดี

หรือบางทีคุณอาจพิจารณาแล้วว่าในบริบทชีวิตจริงมีบางอย่างช้าเกินไปหรือใช้ความจำมากเกินไป

ตกลง, ตอนนี้ คุณสามารถเพิ่มประสิทธิภาพ

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

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

วิธีรับเวลาปัจจุบันในจาวาสคริปต์

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

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

เทคนิคโดยรวม

ก่อนอื่นอย่าลืมอยู่ในระดับสูงให้นานที่สุด:

เธอรู้รึเปล่า? เคล็ดลับการเพิ่มประสิทธิภาพสากลขั้นสูงสุดใช้ได้ในทุกกรณี:

- วาดสิ่งของน้อยลง
- อัปเดตสิ่งต่างๆน้อยลง

- Lars Doucet (@larsiusprime) 30 มีนาคม 2560

ในระดับอัลกอริทึมทั้งหมดเทคนิคหนึ่งคือ ลดความแข็งแรง . ในกรณีของการลดลูปลงในสูตร แต่โปรดระมัดระวังในการแสดงความคิดเห็น ไม่ใช่ทุกคนที่รู้จักหรือจำสูตร Combinatorics ได้ทุกสูตร นอกจากนี้โปรดใช้ความระมัดระวังในการใช้คณิตศาสตร์: บางครั้งสิ่งที่คุณคิดว่าอาจเป็นการลดความแข็งแกร่งไม่ใช่ในท้ายที่สุด ตัวอย่างเช่นสมมติว่า x * (y + z) มีความหมายของอัลกอริทึมที่ชัดเจน หากสมองของคุณได้รับการฝึกฝนในบางจุดไม่ว่าจะด้วยเหตุผลใดก็ตามให้ยกเลิกการจัดกลุ่มคำที่คล้ายกันโดยอัตโนมัติคุณอาจถูกล่อลวงให้เขียนใหม่เป็น x * y + x * z ประการหนึ่งสิ่งนี้ทำให้เกิดกำแพงกั้นระหว่างผู้อ่านและความหมายของอัลกอริทึมที่ชัดเจนที่เคยมีมา (แย่กว่านั้นคือตอนนี้จริงๆแล้ว น้อยกว่า มีประสิทธิภาพเนื่องจากต้องมีการดำเนินการคูณพิเศษ มันเหมือนกับการปลดห่วงเพียงแค่ทำให้กางเกงหลุด) ไม่ว่าในกรณีใดข้อความสั้น ๆ เกี่ยวกับความตั้งใจของคุณจะไปได้ไกลและอาจช่วยให้คุณเห็นข้อผิดพลาดของตัวเองก่อนที่จะกระทำ

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

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

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

การเพิ่มประสิทธิภาพไมโคร

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

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

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

ณ จุดนี้ขึ้นอยู่กับบริบทและข้อกำหนดในการปรับขนาด Jeff Atwood อาจแนะนำ เพียงแค่เพิ่มฮาร์ดแวร์ ซึ่งอาจถูกกว่าเวลาของนักพัฒนาซอฟต์แวร์

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

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

โดยเฉพาะอย่างยิ่ง:

• เคล็ดลับการเพิ่มประสิทธิภาพโค้ดใน C และ C ++
• เคล็ดลับการเพิ่มประสิทธิภาพโค้ดใน Java
• การเพิ่มประสิทธิภาพการใช้งาน CPU ใน. NET
• ASP.NET เว็บแคชฟาร์ม
• การปรับฐานข้อมูล SQL หรือ การปรับแต่ง Microsoft SQL Server โดยเฉพาะ
• Scaling Scala’s Play! กรอบ
• การเพิ่มประสิทธิภาพขั้นสูงของ WordPress
• การเพิ่มประสิทธิภาพโค้ดด้วยต้นแบบ JavaScript และโซ่ขอบเขต
• การเพิ่มประสิทธิภาพการตอบสนอง
• ประสิทธิภาพของแอนิเมชั่น iOS
• เคล็ดลับประสิทธิภาพ Android

ไม่ว่าในกรณีใด ๆ ฉัน ทำ มีอะไรเพิ่มเติม สิ่งที่ไม่ควรทำ สำหรับคุณ:

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

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

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

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

เป็นของคุณ: การเพิ่มประสิทธิภาพที่ดีที่สุด

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

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

ทำความเข้าใจพื้นฐาน

การเพิ่มประสิทธิภาพซอฟต์แวร์หมายถึงอะไร

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

การเพิ่มประสิทธิภาพคืออะไร

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

การเพิ่มประสิทธิภาพลูปคืออะไร?

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

อะไรคือความเสี่ยงโดยทั่วไปเมื่อเราเพิ่มประสิทธิภาพก่อนกำหนด?

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

อะไรคือขั้นตอนการเพิ่มประสิทธิภาพโค้ดก่อนเขียนโค้ด?

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

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

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