ไม่ว่าคุณจะพัฒนาแอปพลิเคชันประเภทใด การเพิ่มประสิทธิภาพของแอปพลิเคชัน การตรวจสอบว่าแอปพลิเคชันโหลดได้อย่างรวดเร็ว และมอบการโต้ตอบที่ราบรื่นนั้นสำคัญอย่างยิ่งต่อประสบการณ์ของผู้ใช้และความสำเร็จของแอปพลิเคชัน วิธีหนึ่งในการทำเช่นนี้คือการสํารวจกิจกรรมของแอปพลิเคชันโดยใช้เครื่องมือการสร้างโปรไฟล์เพื่อดูสิ่งที่เกิดขึ้นเบื้องหลังขณะที่แอปพลิเคชันทํางานในช่วงระยะเวลาหนึ่ง แผงประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บเป็นเครื่องมือโปรไฟล์ที่ยอดเยี่ยมในการวิเคราะห์และเพิ่มประสิทธิภาพของเว็บแอปพลิเคชัน หากแอปของคุณกำลังทำงานใน Chrome แอปจะแสดงภาพรวมโดยละเอียดเกี่ยวกับสิ่งที่เบราว์เซอร์กำลังทำขณะที่แอปพลิเคชันของคุณกำลังดำเนินการ การทำความเข้าใจกิจกรรมนี้จะช่วยให้คุณระบุรูปแบบ จุดคอขวด และจุดที่มีประสิทธิภาพต่ำซึ่งคุณดำเนินการเพื่อปรับปรุงประสิทธิภาพได้
ตัวอย่างต่อไปนี้จะอธิบายวิธีใช้แผงประสิทธิภาพ
การตั้งค่าและสร้างสถานการณ์การจัดทำโปรไฟล์อีกครั้ง
เมื่อไม่นานมานี้ เราได้ตั้งเป้าหมายเพื่อปรับปรุงประสิทธิภาพของแผงประสิทธิภาพให้ดียิ่งขึ้น โดยเฉพาะอย่างยิ่ง เราต้องการให้โหลดข้อมูลประสิทธิภาพจํานวนมากได้เร็วขึ้น ตัวอย่างเช่น เมื่อสร้างโปรไฟล์กระบวนการที่ทำงานนานหรือซับซ้อน หรือบันทึกข้อมูลที่ละเอียดสูง ในการบรรลุเป้าหมายนี้ คุณต้องเข้าใจประสิทธิภาพการทำงานของแอปพลิเคชันและสาเหตุที่มีการทำงานในลักษณะนั้นเป็นอันดับแรก ซึ่งทำได้โดยใช้เครื่องมือการทำโปรไฟล์
ดังที่คุณทราบ เครื่องมือสำหรับนักพัฒนาเว็บเองก็เป็นเว็บแอปพลิเคชัน คุณจึงสร้างโปรไฟล์ได้โดยใช้แผงประสิทธิภาพ หากต้องการสํารวจแผงนี้โดยเฉพาะ ให้เปิดเครื่องมือสําหรับนักพัฒนาเว็บ แล้วเปิดอินสแตนซ์เครื่องมือสําหรับนักพัฒนาเว็บอีกรายการที่แนบมากับแผงนี้ ที่ Google การตั้งค่านี้เรียกว่าเครื่องมือสำหรับนักพัฒนาเว็บ
เมื่อตั้งค่าเสร็จแล้ว คุณจะต้องสร้างและบันทึกสถานการณ์ที่จะสร้างโปรไฟล์อีกครั้ง เราจะเรียกหน้าต่าง DevTools เดิมว่า "อินสแตนซ์ DevTools แรก" และเรียกหน้าต่างที่ตรวจสอบอินสแตนซ์แรกว่า "อินสแตนซ์ DevTools ที่ 2" เพื่อไม่ให้เกิดความสับสน
ในอินสแตนซ์ที่ 2 ของเครื่องมือสำหรับนักพัฒนาเว็บ แผงประสิทธิภาพซึ่งต่อจากนี้จะเรียกว่าแผงประสิทธิภาพ สังเกตอินสแตนซ์แรกของเครื่องมือสำหรับนักพัฒนาเว็บเพื่อสร้างสถานการณ์จำลองซึ่งจะโหลดโปรไฟล์
ในอินสแตนซ์ 2 ของ DevTools ระบบจะเริ่มบันทึกสด ขณะที่ในอินสแตนซ์ 1 ระบบจะโหลดโปรไฟล์จากไฟล์บนดิสก์ ระบบจะโหลดไฟล์ขนาดใหญ่เพื่อประเมินประสิทธิภาพการประมวลผลอินพุตขนาดใหญ่อย่างถูกต้อง เมื่ออินสแตนซ์ทั้ง 2 โหลดโหลดเสร็จแล้ว ข้อมูลการสร้างโปรไฟล์ประสิทธิภาพซึ่งมักเรียกว่าการติดตาม จะแสดงในอินสแตนซ์ที่ 2 ของแผงประสิทธิภาพที่โหลดโปรไฟล์
สถานะเริ่มต้น: ระบุโอกาสในการปรับปรุง
หลังจากโหลดเสร็จแล้ว เราสังเกตเห็นข้อมูลต่อไปนี้ในอินสแตนซ์แผงประสิทธิภาพที่ 2 ในภาพหน้าจอถัดไป โฟกัสที่กิจกรรมของเธรดหลัก ซึ่งจะปรากฏใต้แทร็กที่มีป้ายกำกับว่าหลัก จะเห็นได้ว่าแผนภูมิเปลวไฟมีกิจกรรมอยู่ 5 กลุ่มใหญ่ๆ ซึ่งประกอบด้วยงานที่ใช้เวลาโหลดนานที่สุด ระยะเวลาทั้งหมดของงานเหล่านี้คือประมาณ 10 วินาที ในภาพหน้าจอต่อไปนี้ มีการใช้แผงประสิทธิภาพเพื่อมุ่งเน้นที่กลุ่มกิจกรรมแต่ละกลุ่มเหล่านี้เพื่อดูสิ่งที่พบ
กลุ่มกิจกรรมแรก: งานที่ไม่จำเป็น
เราสังเกตเห็นว่ากิจกรรมกลุ่มแรกคือโค้ดเดิมที่ยังทำงานอยู่ แต่ไม่จำเป็นจริงๆ โดยพื้นฐานแล้ว ทุกอย่างที่อยู่ภายใต้บล็อกสีเขียวที่ติดป้ายกํากับว่า processThreadEvents นั้นเป็นการทํางานเปล่าประโยชน์ นั่นคือชัยชนะอย่างรวดเร็ว การนำการเรียกใช้ฟังก์ชันนั้นออกจะประหยัดเวลาได้ประมาณ 1.5 วินาที เยี่ยมเลย
กลุ่มกิจกรรมที่ 2
ส่วนในกลุ่มกิจกรรมที่ 2 วิธีแก้ปัญหาไม่ได้ง่ายเหมือนกับรายการแรก buildProfileCalls ใช้เวลาประมาณ 0.5 วินาที และงานดังกล่าวเป็นสิ่งที่หลีกเลี่ยงไม่ได้
เราเปิดใช้ตัวเลือกหน่วยความจําในแผงประสิทธิภาพเพื่อตรวจสอบเพิ่มเติม และพบว่ากิจกรรม buildProfileCalls ใช้หน่วยความจํามากเช่นกัน ในส่วนนี้ คุณจะเห็นกราฟเส้นสีฟ้าเพิ่มขึ้นอย่างฉับพลันในช่วงที่มีการทำงาน buildProfileCalls ซึ่งบ่งชี้ว่าอาจมีการสูญเสียหน่วยความจํา
เราใช้แผงหน่วยความจำ (แผงอื่นในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ ซึ่งแตกต่างจากลิ้นชักหน่วยความจำในแผงประสิทธิภาพ) เพื่อตรวจสอบความเป็นไปได้นี้ ในแผงหน่วยความจํา มีการกําหนดประเภทการโปรไฟล์เป็น "การสุ่มตัวอย่างการจัดสรร" ซึ่งบันทึกภาพรวมฮีปสําหรับแผงประสิทธิภาพที่โหลดโปรไฟล์ CPU
ภาพหน้าจอต่อไปนี้แสดงฮีพสแนปชอตที่รวบรวมไว้
จากภาพรวมกองขยะนี้ เราพบว่าคลาส Set ใช้หน่วยความจํามาก จากการตรวจสอบจุดเรียก เราพบว่าเราได้กำหนดพร็อพเพอร์ตี้ประเภท Set ให้กับออบเจ็กต์ที่สร้างขึ้นเป็นจำนวนมากโดยไม่จำเป็น ค่าใช้จ่ายนี้เพิ่มขึ้นเรื่อยๆ และหน่วยความจําถูกใช้ไปมากจนแอปพลิเคชันมักจะขัดข้องเมื่อป้อนข้อมูลจำนวนมาก
ชุดจะมีประโยชน์ในการจัดเก็บรายการที่ไม่ซ้ำกัน และให้การดำเนินการที่ใช้ความไม่ซ้ำกันของเนื้อหา เช่น การทำซ้ำชุดข้อมูล และในการค้นหาที่มีประสิทธิภาพมากขึ้น อย่างไรก็ตาม ฟีเจอร์เหล่านั้นไม่จําเป็นเนื่องจากระบบรับประกันว่าข้อมูลที่จัดเก็บจะไม่ซ้ำกันจากแหล่งที่มา ดังนั้นชุดจึงไม่จำเป็นต้องมีตั้งแต่แรก เปลี่ยนประเภทพร็อพเพอร์ตี้จาก Set เป็นอาร์เรย์ธรรมดาเพื่อปรับปรุงการจัดสรรหน่วยความจํา หลังจากใช้การเปลี่ยนแปลงนี้ เราได้จับภาพฮีปอีกภาพหนึ่งและพบว่ามีการลดการจัดสรรหน่วยความจำ แม้ว่าการเปลี่ยนแปลงนี้จะไม่ช่วยปรับปรุงความเร็วได้มากนัก แต่ข้อดีรองคือแอปพลิเคชันขัดข้องน้อยลง
กลุ่มกิจกรรมที่ 3: พิจารณาข้อดีข้อเสียของโครงสร้างข้อมูล
ส่วนที่สามมีความแปลกประหลาด: คุณจะเห็นในแผนภูมิเปลวไฟว่าส่วนนี้ประกอบด้วยคอลัมน์ที่แคบแต่สูง ซึ่งแสดงถึงคําเรียกฟังก์ชันที่ลึก และการเรียกซ้ำที่ลึกในกรณีนี้ โดยรวมแล้ว โฆษณาส่วนนี้ใช้เวลาประมาณ 1.4 วินาที เมื่อดูที่ด้านล่างของส่วนนี้ เราพบว่าความกว้างของคอลัมน์เหล่านี้กำหนดโดยระยะเวลาของฟังก์ชัน 1 รายการ appendEventAtLevel ซึ่งแนะนำว่าอาจเป็นจุดคอขวด
สิ่งหนึ่งที่โดดเด่นในการใช้งานฟังก์ชัน appendEventAtLevel สําหรับข้อมูลรายการเดียวในอินพุต (ซึ่งเรียกว่า "เหตุการณ์" ในโค้ด) ระบบจะเพิ่มรายการลงในแผนที่ซึ่งติดตามตําแหน่งแนวตั้งของรายการไทม์ไลน์ ซึ่งทำให้เกิดปัญหาเนื่องจากมีจำนวนรายการที่จัดเก็บไว้เป็นจำนวนมาก Maps ค้นหาตามคีย์ได้อย่างรวดเร็ว แต่ข้อดีนี้ไม่ได้มีให้ฟรี เมื่อแผนที่มีขนาดใหญ่ขึ้น การเพิ่มข้อมูลลงในแผนที่อาจทำให้เสียค่าใช้จ่ายเนื่องจากต้องมีการแฮชใหม่ ค่าใช้จ่ายนี้จะเห็นได้ชัดเมื่อมีการเพิ่มรายการจำนวนมากลงในแผนที่อย่างต่อเนื่อง
/**
* Adds an event to the flame chart data at a defined vertical level.
*/
function appendEventAtLevel (event, level) {
// ...
const index = data.length;
data.push(event);
this.indexForEventMap.set(event, index);
// ...
}
เราลองใช้แนวทางอื่นที่ไม่จําเป็นต้องเพิ่มรายการในแผนที่สําหรับทุกรายการในแผนภูมิเปลวไฟ การปรับปรุงนี้ได้ผลอย่างมาก ซึ่งยืนยันว่าปัญหาคอขวดเกี่ยวข้องกับค่าใช้จ่ายเพิ่มเติมที่เกิดขึ้นจากการเพิ่มข้อมูลทั้งหมดลงในแผนที่ เวลาที่กลุ่มกิจกรรมใช้เวลาหดตัวจากประมาณ 1.4 วินาทีเป็นประมาณ 200 มิลลิวินาที
ก่อน:
หลัง:
กลุ่มกิจกรรมที่ 4: การเลื่อนงานที่ไม่สำคัญและแคชข้อมูลเพื่อป้องกันการทำงานซ้ำ
เมื่อซูมเข้าที่หน้าต่างนี้ จะเห็นว่ามีบล็อกการเรียกฟังก์ชันที่เกือบเหมือนกัน 2 บล็อก เมื่อดูชื่อของฟังก์ชันที่เรียกใช้ คุณจะอนุมานได้ว่าบล็อกเหล่านี้ประกอบด้วยโค้ดที่สร้างต้นไม้ (เช่น มีชื่อเป็น refreshTree หรือ buildChildren) อันที่จริงแล้ว โค้ดที่เกี่ยวข้องคือโค้ดที่สร้างมุมมองต้นไม้ในลิ้นชักด้านล่างของแผง สิ่งที่น่าสนใจคือมุมมองแผนภูมิต้นไม้เหล่านี้จะไม่แสดงทันทีหลังจากโหลด แต่ผู้ใช้ต้องเลือกมุมมองแผนภูมิต้นไม้ (แท็บ "จากล่างขึ้นบน" "แผนภูมิการเรียก" และ "บันทึกเหตุการณ์" ในลิ้นชัก) เพื่อให้แผนภูมิต้นไม้แสดง นอกจากนี้ จากภาพหน้าจอที่เห็นได้มีการดำเนินการสร้างต้นไม้ 2 ครั้ง
มีปัญหา 2 ข้อที่เราพบในรูปภาพนี้
- งานที่ไม่สำคัญกำลังขัดขวางประสิทธิภาพของเวลาในการโหลด ผู้ใช้ไม่จำเป็นต้องใช้เอาต์พุตเสมอไป ดังนั้น งานนี้จึงไม่ใช่งานที่สําคัญต่อการโหลดโปรไฟล์
- ระบบไม่ได้แคชผลลัพธ์ของงานเหล่านี้ ด้วยเหตุนี้ ระบบจึงคำนวณต้นไม้ 2 ครั้ง แม้ว่าข้อมูลจะไม่เปลี่ยนแปลง
เราเริ่มด้วยการเลื่อนการคำนวณแผนภูมิต้นไม้ออกไปจนกว่าผู้ใช้จะเปิดมุมมองแผนภูมิต้นไม้ด้วยตนเอง เมื่อนั้นการสร้างต้นไม้เหล่านี้จึงคุ้มค่า เวลาทั้งหมดในการเรียกใช้ 2 ครั้งคือประมาณ 3.4 วินาที ดังนั้นการเลื่อนเวลาจึงทําให้เวลาในการโหลดแตกต่างกันอย่างมาก เรายังตรวจสอบการแคชงานประเภทเหล่านี้ด้วย
กลุ่มกิจกรรมที่ 5: หลีกเลี่ยงลําดับชั้นการเรียกที่ซับซ้อนหากเป็นไปได้
เมื่อพิจารณากลุ่มนี้อย่างละเอียด พบว่ามีการเรียกใช้เชนการเรียกใช้หนึ่งๆ ซ้ำๆ รูปแบบเดียวกันนี้ปรากฏขึ้น 6 ครั้งในตำแหน่งต่างๆ ในแผนภูมิเปลวไฟ และระยะเวลารวมของหน้าต่างนี้อยู่ที่ประมาณ 2.4 วินาที
โค้ดที่เกี่ยวข้องซึ่งเรียกใช้หลายครั้งคือส่วนที่ประมวลผลข้อมูลที่จะแสดงผลใน "แผนที่ขนาดเล็ก" (ภาพรวมของกิจกรรมไทม์ไลน์ที่ด้านบนของแผง) เราไม่แน่ใจว่าเหตุใดจึงเกิดขึ้นหลายครั้ง แต่ไม่ควรเกิดขึ้นถึง 6 ครั้ง อันที่จริงแล้ว เอาต์พุตของโค้ดควรเป็นปัจจุบันอยู่เสมอหากไม่มีการโหลดโปรไฟล์อื่น ในทางทฤษฎี โค้ดควรทำงานเพียงครั้งเดียว
จากการตรวจสอบ เราพบว่ามีการเรียกใช้โค้ดที่เกี่ยวข้องเนื่องจากหลายส่วนในไปป์ไลน์การโหลดเรียกใช้ฟังก์ชันที่คำนวณแผนที่ขนาดเล็กโดยตรงหรือโดยอ้อม เนื่องจากความซับซ้อนของกราฟการเรียกใช้ของโปรแกรมมีการเปลี่ยนแปลงไปเมื่อเวลาผ่านไป และมีการเพิ่มความเกี่ยวข้องกับโค้ดนี้โดยไม่รู้ตัว ปัญหานี้ไม่มีวิธีแก้ไขด่วน วิธีแก้โจทย์จะขึ้นอยู่กับสถาปัตยกรรมของฐานของโค้ดที่เป็นปัญหา ในกรณีของเรา เราต้องลดความซับซ้อนของลําดับชั้นการเรียกใช้ลงเล็กน้อยและเพิ่มการตรวจสอบเพื่อป้องกันไม่ให้โค้ดทํางานหากข้อมูลอินพุตไม่มีการเปลี่ยนแปลง หลังจากติดตั้งใช้งานแล้ว เราได้รับภาพรวมของไทม์ไลน์ดังนี้
โปรดทราบว่าการเรียกใช้การแสดงผลแผนที่ขนาดเล็กจะเกิดขึ้น 2 ครั้ง ไม่ใช่ 1 ครั้ง เนื่องจากมีการวาดแผนที่ขนาดย่อ 2 ขนาดสำหรับทุกโปรไฟล์: ตารางหนึ่งแสดงภาพรวมที่ด้านบนของแผง และอีกรายการหนึ่งสำหรับเมนูแบบเลื่อนลงที่เลือกโปรไฟล์ที่ปรากฏอยู่ในปัจจุบันจากประวัติ (ทุกรายการในเมนูนี้ประกอบด้วยภาพรวมของโปรไฟล์ที่เลือกอยู่) อย่างไรก็ตาม 2 รายการนี้มีเนื้อหาเหมือนกันทุกประการ คุณจึงนํารายการใดรายการหนึ่งไปใช้กับอีกรายการหนึ่งได้
เนื่องจากแผนที่ขนาดเล็กเหล่านี้เป็นทั้งรูปภาพที่วาดบนผืนผ้าใบ จึงต้องใช้drawImage ยูทิลิตีผืนผ้าใบ และเรียกใช้โค้ดเพียงครั้งเดียวเพื่อประหยัดเวลา ความพยายามนี้ทำให้ระยะเวลาของกลุ่มลดลงจาก 2.4 วินาทีเป็น 140 มิลลิวินาที
บทสรุป
หลังจากใช้การแก้ไขเหล่านี้ทั้งหมดแล้ว (และการแก้ไขเล็กๆ น้อยๆ อีก 2-3 รายการที่นี่) การเปลี่ยนแปลงไทม์ไลน์การโหลดโปรไฟล์จะมีลักษณะดังนี้
ก่อน:
หลัง:
เวลาในการโหลดหลังจากการปรับปรุงคือ 2 วินาที ซึ่งหมายความว่าการปรับปรุงประมาณ 80% นั้นทําได้โดยใช้ความพยายามเพียงเล็กน้อย เนื่องจากสิ่งที่ทําส่วนใหญ่เป็นการแก้ไขด่วน แน่นอนว่าการระบุสิ่งที่ต้องทำอย่างถูกต้องตั้งแต่แรกเป็นกุญแจสำคัญ และแผงประสิทธิภาพเป็นเครื่องมือที่เหมาะสมสําหรับงานนี้
นอกจากนี้ เราขอเน้นย้ำว่าตัวเลขเหล่านี้เกี่ยวข้องกับโปรไฟล์ที่ใช้เป็นหัวข้อการศึกษาโดยเฉพาะ โปรไฟล์นี้น่าสนใจสำหรับเราเพราะมีขนาดใหญ่มาก อย่างไรก็ตาม เนื่องจากไปป์ไลน์การประมวลผลจะเหมือนกันสำหรับทุกโปรไฟล์ การปรับปรุงที่สำคัญที่ได้จึงมีผลกับทุกโปรไฟล์ที่โหลดในแผงประสิทธิภาพ
สรุปประเด็นสำคัญ
บทเรียนที่ได้จากผลลัพธ์เหล่านี้ในแง่การเพิ่มประสิทธิภาพแอปพลิเคชันมีดังนี้
1. ใช้เครื่องมือโปรไฟล์เพื่อระบุรูปแบบประสิทธิภาพรันไทม์
เครื่องมือโปรไฟล์มีประโยชน์อย่างยิ่งในการทําความเข้าใจสิ่งที่เกิดขึ้นในแอปพลิเคชันขณะทํางาน โดยเฉพาะในการระบุโอกาสในการปรับปรุงประสิทธิภาพ แผงประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของ Chrome เป็นตัวเลือกที่ยอดเยี่ยมสำหรับเว็บแอปพลิเคชัน เนื่องจากเป็นเครื่องมือสร้างโปรไฟล์เว็บในตัวของเบราว์เซอร์ และได้รับการดูแลรักษาอย่างสม่ำเสมอเพื่อให้เป็นปัจจุบันกับฟีเจอร์แพลตฟอร์มเว็บล่าสุด นอกจากนี้ การดำเนินการยังเร็วขึ้นมากด้วย 😉
ใช้ตัวอย่างที่สามารถใช้เป็นภาระงานที่แสดงถึงภาพรวม แล้วดูสิ่งที่พบ
2. หลีกเลี่ยงลำดับชั้นการโทรที่ซับซ้อน
หลีกเลี่ยงการทำกราฟการโทรให้ซับซ้อนเกินไป หากเป็นไปได้ ลําดับชั้นการเรียกที่ซับซ้อนทําให้ประสิทธิภาพถดถอยได้ง่ายและทําให้เข้าใจสาเหตุที่โค้ดทํางานในลักษณะที่เป็นอยู่ได้ยาก จึงทําให้การปรับปรุงประสบความสําเร็จได้ยาก
3. ระบุงานที่ไม่จำเป็น
การที่โค้ดเบสแบบเก่ามีโค้ดที่ไม่จำเป็นอีกต่อไปนั้นถือเป็นเรื่องปกติ ในกรณีของเรา โค้ดเดิมและโค้ดที่ไม่จำเป็นกินเวลาในการโหลดทั้งหมดไปมาก การนําออกเป็นวิธีที่ง่ายที่สุด
4. ใช้โครงสร้างข้อมูลอย่างเหมาะสม
ใช้โครงสร้างข้อมูลเพื่อเพิ่มประสิทธิภาพ แต่ก็ต้องเข้าใจค่าใช้จ่ายและข้อเสียที่โครงสร้างข้อมูลแต่ละประเภทมีเมื่อตัดสินใจเลือกโครงสร้างที่จะใช้ ซึ่งไม่เพียงแต่เป็นความซับซ้อนด้านพื้นที่ของโครงสร้างข้อมูลเท่านั้น แต่ยังมีความซับซ้อนด้านเวลาของการดำเนินการที่เกี่ยวข้องด้วย
5. แคชผลลัพธ์เพื่อหลีกเลี่ยงการทำงานซ้ำสําหรับการดำเนินการที่ซับซ้อนหรือซ้ำ
หากการดำเนินการมีค่าใช้จ่ายสูง ควรจัดเก็บผลลัพธ์ไว้ในครั้งต่อไปที่ต้องการ นอกจากนี้ การทำเช่นนี้ยังเหมาะสมในกรณีที่มีการดำเนินการหลายครั้ง แม้ว่าแต่ละครั้งจะเสียค่าใช้จ่ายไม่มากนักก็ตาม
6. เลื่อนงานที่ไม่สำคัญออกไป
หากไม่จําเป็นต้องใช้เอาต์พุตของงานในทันทีและการดำเนินการของงานจะขยายเส้นทางที่สำคัญ ให้พิจารณาเลื่อนเวลาโดยเรียกใช้แบบ Lazy เมื่อจําเป็นต้องใช้เอาต์พุตจริงๆ
7. ใช้อัลกอริทึมที่มีประสิทธิภาพกับอินพุตขนาดใหญ่
สําหรับอินพุตขนาดใหญ่ อัลกอริทึมความซับซ้อนของเวลาแบบเพิ่มประสิทธิภาพสูงสุดจะกลายเป็นสิ่งสําคัญ เราไม่ได้ตรวจสอบหมวดหมู่นี้ในตัวอย่างนี้ แต่ความสำคัญของหมวดหมู่นี้นั้นสำคัญอย่างยิ่ง
8. โบนัส: เปรียบเทียบไปป์ไลน์ของคุณ
คุณควรตรวจสอบลักษณะการทํางานและเปรียบเทียบกับมาตรฐานเพื่อให้แน่ใจว่าโค้ดที่พัฒนาอยู่จะยังคงทํางานได้อย่างรวดเร็ว วิธีนี้จะช่วยให้คุณระบุการถดถอยและปรับปรุงความน่าเชื่อถือโดยรวมได้อย่างต่อเนื่อง ซึ่งจะช่วยให้คุณประสบความสำเร็จในระยะยาว