แผงประสิทธิภาพที่ทำงานเร็วขึ้น 400% ผ่านการรับรู้

Andrés Olivares

Nancy Li

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

ตัวอย่างต่อไปนี้จะอธิบายการใช้แผงประสิทธิภาพ

การตั้งค่าและสร้างสถานการณ์การสร้างโปรไฟล์ใหม่

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

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

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

วันที่

เครื่องมือสำหรับนักพัฒนาเว็บ: ตรวจสอบเครื่องมือสำหรับนักพัฒนาเว็บด้วยเครื่องมือสำหรับนักพัฒนาเว็บ

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

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

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

สถานะเริ่มต้น: ระบุโอกาสในการปรับปรุง

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

กลุ่มกิจกรรมแรก: งานที่ไม่จำเป็น

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

กลุ่มกิจกรรมที่ 2

ส่วนในกลุ่มกิจกรรมที่ 2 โซลูชันนี้ไม่ง่ายเหมือนกับกิจกรรมแรก buildProfileCalls ใช้เวลาประมาณ 0.5 วินาที และงานนั้นไม่ใช่สิ่งที่สามารถหลีกเลี่ยงได้

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

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

ภาพหน้าจอต่อไปนี้แสดงฮีปสแนปชอตที่รวบรวมไว้

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

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

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

กลุ่มกิจกรรมที่ 3: พิจารณาข้อดีข้อเสียของโครงสร้างข้อมูล

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

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

/**
 * 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 ข้อที่เราพบในรูปภาพนี้

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

เราเริ่มจากการเลื่อนเวลาคํานวณแผนผังต้นไม้ไปเมื่อผู้ใช้เปิดมุมมองต้นไม้ด้วยตนเอง เพียงเท่านี้ก็คุ้มค่าที่จะจ่ายในราคาในการสร้างต้นไม้เหล่านี้แล้ว เวลารวมของการเรียกใช้โฆษณา 2 ครั้งอยู่ที่ประมาณ 3.4 วินาที ดังนั้นการยืดเวลานี้สร้างความแตกต่างอย่างมากในเรื่องเวลาที่ใช้ในการโหลด เรายังคงพยายามแคชงานประเภทนี้อยู่เช่นกัน

กลุ่มกิจกรรมที่ 5: หลีกเลี่ยงลำดับชั้นการเรียกใช้ที่ซับซ้อนหากเป็นไปได้

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

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

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

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

เนื่องจากแผนที่ขนาดเล็กเหล่านี้เป็นรูปภาพทั้ง 2 ภาพที่วาดบนผืนผ้าใบ จึงใช้ยูทิลิตี Canvas ของ drawImage และการเรียกใช้โค้ดเพียงครั้งเดียวเพื่อประหยัดเวลา ความพยายามนี้ทำให้ระยะเวลาของกลุ่มลดลงจาก 2.4 วินาทีเป็น 140 มิลลิวินาที

บทสรุป

หลังจากใช้การแก้ไขเหล่านี้ทั้งหมดแล้ว (และการแก้ไขเล็กๆ น้อยๆ อีก 2-3 รายการที่นี่) การเปลี่ยนแปลงไทม์ไลน์การโหลดโปรไฟล์จะมีลักษณะดังนี้

ก่อน:

หลัง:

วันที่

หมายเหตุ: กรอบเวลาที่เลือกของ "ก่อน" ภาพหน้าจอยาว 15 วินาที และ 2.4 วินาทีสำหรับ "หลัง" ภาพหน้าจอ

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

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

สรุปประเด็นสำคัญ

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

1. ใช้เครื่องมือสร้างโปรไฟล์เพื่อระบุรูปแบบประสิทธิภาพรันไทม์

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

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

2. หลีกเลี่ยงลำดับชั้นการโทรที่ซับซ้อน

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

3. ระบุงานที่ไม่จำเป็น

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

4. ใช้โครงสร้างข้อมูลอย่างเหมาะสม

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

5. แคชผลลัพธ์เพื่อหลีกเลี่ยงการทำงานที่ซ้ำกันสำหรับการดำเนินการที่ซับซ้อนหรือซ้ำๆ

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

6. เลื่อนงานที่ไม่สำคัญ

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

7. ใช้อัลกอริทึมที่มีประสิทธิภาพกับอินพุตขนาดใหญ่

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

8. โบนัส: เปรียบเทียบไปป์ไลน์ของคุณ

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