ไม่ว่าคุณจะพัฒนาแอปพลิเคชันประเภทใด การเพิ่มประสิทธิภาพของแอปพลิเคชัน การตรวจสอบว่าแอปพลิเคชันโหลดได้เร็วและมีการโต้ตอบที่ราบรื่นเป็นสิ่งสําคัญอย่างยิ่งต่อประสบการณ์ของผู้ใช้และความสําเร็จของแอปพลิเคชัน วิธีหนึ่งในการทำเช่นนี้คือการสํารวจกิจกรรมของแอปพลิเคชันโดยใช้เครื่องมือการสร้างโปรไฟล์เพื่อดูสิ่งที่เกิดขึ้นเบื้องหลังขณะที่แอปพลิเคชันทํางานในช่วงระยะเวลาหนึ่ง แผงประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บเป็นเครื่องมือโปรไฟล์ที่ยอดเยี่ยมในการวิเคราะห์และเพิ่มประสิทธิภาพของเว็บแอปพลิเคชัน หากแอปทำงานใน Chrome ฟีเจอร์นี้จะแสดงภาพรวมโดยละเอียดเกี่ยวกับสิ่งที่เบราว์เซอร์ทําขณะที่แอปพลิเคชันทำงาน การทำความเข้าใจกิจกรรมนี้จะช่วยให้คุณระบุรูปแบบ จุดคอขวด และจุดที่มีประสิทธิภาพต่ำซึ่งสามารถดำเนินการเพื่อปรับปรุงประสิทธิภาพได้
ตัวอย่างต่อไปนี้จะอธิบายวิธีใช้แผงประสิทธิภาพ
การตั้งค่าและสร้างสถานการณ์การจัดทำโปรไฟล์อีกครั้ง
เมื่อไม่นานมานี้ เราได้ตั้งเป้าหมายเพื่อปรับปรุงประสิทธิภาพของแผงประสิทธิภาพให้ดียิ่งขึ้น โดยเฉพาะอย่างยิ่ง เราต้องการให้โหลดข้อมูลประสิทธิภาพจํานวนมากได้เร็วขึ้น ตัวอย่างเช่น เมื่อสร้างโปรไฟล์กระบวนการที่ทำงานนานหรือซับซ้อน หรือบันทึกข้อมูลที่ละเอียดสูง ในการทำเช่นนี้ คุณต้องเข้าใจวิธีที่แอปพลิเคชันทำงานและเหตุผลที่ทำงานแบบนั้น ซึ่งทำได้โดยใช้เครื่องมือโปรไฟล์
ดังที่คุณทราบ เครื่องมือสำหรับนักพัฒนาเว็บเองก็เป็นเว็บแอปพลิเคชัน คุณจึงสร้างโปรไฟล์ได้โดยใช้แผงประสิทธิภาพ หากต้องการสํารวจแผงนี้โดยเฉพาะ ให้เปิดเครื่องมือสําหรับนักพัฒนาเว็บ แล้วเปิดอินสแตนซ์เครื่องมือสําหรับนักพัฒนาเว็บอีกรายการที่แนบมากับแผง ที่ Google เราเรียกการตั้งค่านี้ว่า DevTools-on-DevTools
เมื่อตั้งค่าเสร็จแล้ว คุณจะต้องสร้างและบันทึกสถานการณ์ที่จะสร้างโปรไฟล์อีกครั้ง เราจะเรียกหน้าต่าง DevTools เดิมว่า "อินสแตนซ์ DevTools แรก" และเรียกหน้าต่างที่ตรวจสอบอินสแตนซ์แรกว่า "อินสแตนซ์ DevTools ที่ 2" เพื่อไม่ให้เกิดความสับสน
ในอินสแตนซ์ DevTools ที่ 2 แผงประสิทธิภาพ ซึ่งจะเรียกว่าแผงประสิทธิภาพนับจากนี้เป็นต้นไป จะสังเกตอินสแตนซ์ DevTools แรกเพื่อสร้างสถานการณ์ขึ้นมาใหม่ ซึ่งจะโหลดโปรไฟล์
ในอินสแตนซ์ 2 ของ DevTools ระบบจะเริ่มบันทึกสด ส่วนในอินสแตนซ์ 1 ระบบจะโหลดโปรไฟล์จากไฟล์บนดิสก์ ระบบจะโหลดไฟล์ขนาดใหญ่เพื่อประเมินประสิทธิภาพการประมวลผลอินพุตขนาดใหญ่อย่างถูกต้อง เมื่ออินสแตนซ์ทั้ง 2 รายการโหลดเสร็จแล้ว คุณจะเห็นข้อมูลโปรไฟล์ประสิทธิภาพหรือที่เรียกกันทั่วไปว่าการติดตามในอินสแตนซ์ DevTools ที่ 2 ของแผงประสิทธิภาพที่โหลดโปรไฟล์
สถานะเริ่มต้น: ระบุโอกาสในการปรับปรุง
หลังจากการโหลดเสร็จสิ้นแล้ว เราสังเกตเห็นข้อมูลต่อไปนี้ในอินสแตนซ์แผงประสิทธิภาพที่ 2 ในภาพหน้าจอถัดไป โฟกัสที่กิจกรรมของเธรดหลัก ซึ่งจะปรากฏในแทร็กที่มีป้ายกำกับว่าหลัก จะเห็นได้ว่าแผนภูมิเปลวไฟมีกิจกรรมอยู่ 5 กลุ่มใหญ่ๆ ซึ่งประกอบด้วยงานที่ใช้เวลาโหลดนานที่สุด ระยะเวลาทั้งหมดของงานเหล่านี้คือประมาณ 10 วินาที ในภาพหน้าจอต่อไปนี้ มีการใช้แผงประสิทธิภาพเพื่อมุ่งเน้นที่กลุ่มกิจกรรมแต่ละกลุ่มเหล่านี้เพื่อดูสิ่งที่พบ
กลุ่มกิจกรรมแรก: งานที่ไม่จำเป็น
เห็นได้ชัดว่ากลุ่มกิจกรรมแรกเป็นโค้ดเดิมที่ยังคงทํางานอยู่ แต่ก็ไม่จําเป็นจริงๆ โดยพื้นฐานแล้ว ทุกอย่างที่อยู่ภายใต้บล็อกสีเขียวที่ติดป้ายกํากับว่า processThreadEvents นั้นเป็นการทํางานเปล่าประโยชน์ ปัญหานี้แก้ไขได้อย่างรวดเร็ว การนําการเรียกฟังก์ชันดังกล่าวออกช่วยประหยัดเวลาได้ประมาณ 1.5 วินาที เยี่ยมเลย
กลุ่มกิจกรรมที่ 2
ในกลุ่มกิจกรรมที่ 2 โซลูชันไม่ได้ง่ายเหมือนกลุ่มแรก buildProfileCalls ใช้เวลาประมาณ 0.5 วินาที และงานดังกล่าวเป็นสิ่งที่หลีกเลี่ยงไม่ได้
เราเปิดใช้ตัวเลือกหน่วยความจําในแผงประสิทธิภาพเพื่อตรวจสอบเพิ่มเติม และพบว่ากิจกรรม buildProfileCalls ใช้หน่วยความจํามากเช่นกัน ในส่วนนี้ คุณจะเห็นกราฟเส้นสีฟ้าเพิ่มขึ้นอย่างฉับพลันในช่วงที่มีการเรียกใช้ buildProfileCalls ซึ่งอาจบ่งบอกถึงการรั่วไหลของหน่วยความจํา
เราใช้แผงหน่วยความจำ (แผงอื่นในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ ซึ่งแตกต่างจากลิ้นชักหน่วยความจำในแผงประสิทธิภาพ) เพื่อตรวจสอบความเป็นไปได้นี้ ในแผงหน่วยความจํา มีการกําหนดประเภทการโปรไฟล์เป็น "การสุ่มตัวอย่างการจัดสรร" ซึ่งบันทึกภาพรวมฮีปสําหรับแผงประสิทธิภาพที่โหลดโปรไฟล์ CPU
ภาพหน้าจอต่อไปนี้แสดงภาพรวมฮีปที่รวบรวม
จากภาพรวมกองขยะนี้ เราพบว่าคลาส Set ใช้หน่วยความจํามาก จากการตรวจสอบจุดเรียกใช้ เราพบว่าเรากําหนดพร็อพเพอร์ตี้ประเภท Set ให้กับออบเจ็กต์ซึ่งสร้างขึ้นจํานวนมากโดยไม่จําเป็น ค่าใช้จ่ายนี้เพิ่มขึ้นเรื่อยๆ และหน่วยความจําถูกใช้ไปมากจนแอปพลิเคชันมักจะขัดข้องเมื่อป้อนข้อมูลจำนวนมาก
ชุดมีประโยชน์สําหรับการจัดเก็บรายการที่ไม่ซ้ำกันและให้การดำเนินการที่ใช้ความเฉพาะตัวของเนื้อหา เช่น การกรองชุดข้อมูลที่ซ้ำกันออกและการค้นหาที่มีประสิทธิภาพมากขึ้น อย่างไรก็ตาม ฟีเจอร์เหล่านั้นไม่จำเป็นเนื่องจากระบบรับประกันว่าข้อมูลที่จัดเก็บจะไม่ซ้ำกันจากแหล่งที่มา ดังนั้นชุดจึงไม่จำเป็นต้องมีตั้งแต่แรก เปลี่ยนประเภทพร็อพเพอร์ตี้จาก Set เป็นอาร์เรย์ธรรมดาเพื่อปรับปรุงการจัดสรรหน่วยความจํา หลังจากใช้การเปลี่ยนแปลงนี้แล้ว เราถ่ายภาพฮีปอีกภาพหนึ่งและพบว่ามีการลดการจัดสรรหน่วยความจำ แม้ว่าการเปลี่ยนแปลงนี้จะไม่ช่วยปรับปรุงความเร็วได้มากนัก แต่ข้อดีรองคือแอปพลิเคชันขัดข้องน้อยลง
กลุ่มกิจกรรมที่ 3: ชั่งน้ำหนักข้อดีข้อเสียของโครงสร้างข้อมูล
ส่วนที่สามมีความแปลกประหลาด: คุณจะเห็นในแผนภูมิเปลวไฟว่าส่วนนี้ประกอบด้วยคอลัมน์ที่แคบแต่สูง ซึ่งแสดงถึงคําเรียกฟังก์ชันที่ลึก และการเรียกซ้ำที่ลึกในกรณีนี้ โดยรวมแล้ว โฆษณาส่วนนี้ใช้เวลาประมาณ 1.4 วินาที เมื่อดูที่ด้านล่างของส่วนนี้ จะเห็นได้ว่าความกว้างของคอลัมน์เหล่านี้ถูกกําหนดโดยระยะเวลาของฟังก์ชัน 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. เลื่อนงานที่ไม่สำคัญออกไป
หากไม่จําเป็นต้องใช้เอาต์พุตของงานในทันทีและการดำเนินการของงานจะขยายเส้นทางที่สำคัญ ให้พิจารณาเลื่อนเวลาโดยเรียกใช้แบบเลื่อนเวลาเมื่อจําเป็นต้องใช้เอาต์พุตจริงๆ
7. ใช้อัลกอริทึมที่มีประสิทธิภาพกับอินพุตขนาดใหญ่
สําหรับอินพุตขนาดใหญ่ อัลกอริทึมความซับซ้อนของเวลาแบบเพิ่มประสิทธิภาพสูงสุดจะกลายเป็นสิ่งสําคัญ เราไม่ได้ตรวจสอบหมวดหมู่นี้ในตัวอย่างนี้ แต่ความสำคัญของหมวดหมู่นี้นั้นสำคัญอย่างยิ่ง
8. โบนัส: เปรียบเทียบไปป์ไลน์
คุณควรตรวจสอบลักษณะการทํางานและเปรียบเทียบกับมาตรฐานเพื่อให้แน่ใจว่าโค้ดที่พัฒนาจะยังคงทํางานได้อย่างรวดเร็ว วิธีนี้จะช่วยให้คุณระบุการถดถอยและปรับปรุงความน่าเชื่อถือโดยรวมได้อย่างต่อเนื่อง ซึ่งจะช่วยให้คุณประสบความสำเร็จในระยะยาว