ไม่ว่าคุณจะพัฒนาแอปพลิเคชันประเภทใด การเพิ่มประสิทธิภาพของแอปและการตรวจสอบว่าแอปพลิเคชันโหลดได้เร็วและการโต้ตอบที่ราบรื่นถือเป็นสิ่งสำคัญต่อประสบการณ์ของผู้ใช้และความสำเร็จของแอปพลิเคชัน วิธีหนึ่งในการตรวจสอบนี้คือการตรวจสอบกิจกรรมของแอปพลิเคชันโดยใช้เครื่องมือสร้างโปรไฟล์เพื่อดูสิ่งที่เกิดขึ้นเบื้องหลังการทำงานในกรอบเวลา แผงประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บเป็นเครื่องมือที่ยอดเยี่ยมในการทําโปรไฟล์เพื่อวิเคราะห์และเพิ่มประสิทธิภาพเว็บแอปพลิเคชัน หากแอปของคุณกำลังทำงานใน Chrome จะมีภาพรวมโดยละเอียดว่าเบราว์เซอร์กำลังทำอะไรอยู่ขณะที่แอปพลิเคชันของคุณกำลังทำงาน การทำความเข้าใจกิจกรรมนี้ช่วยให้คุณทราบรูปแบบ จุดคอขวด และฮอตสปอตด้านประสิทธิภาพที่คุณสามารถดำเนินการเพื่อปรับปรุงประสิทธิภาพได้
ตัวอย่างต่อไปนี้จะอธิบายเกี่ยวกับการใช้แผงประสิทธิภาพ
การตั้งค่าและสร้างสถานการณ์การสร้างโปรไฟล์ใหม่
เมื่อเร็วๆ นี้เราได้ตั้งเป้าหมายเพื่อทำให้แผงประสิทธิภาพมีประสิทธิภาพมากขึ้น โดยเฉพาะอย่างยิ่ง เราต้องการให้โหลดข้อมูลประสิทธิภาพจำนวนมากได้เร็วยิ่งขึ้น เช่น เมื่อทำการทำโปรไฟล์กระบวนการที่ซับซ้อนหรือใช้เวลานาน หรือการบันทึกข้อมูลที่มีความละเอียดสูง เพื่อบรรลุผลดังกล่าว คุณต้องเข้าใจเกี่ยวกับประสิทธิภาพของแอปพลิเคชันและเหตุผลที่แอปพลิเคชันมีประสิทธิภาพตามนั้นก่อนเป็นอันดับแรก ซึ่งทำได้โดยใช้เครื่องมือการสร้างโปรไฟล์
คุณอาจทราบแล้วว่าเครื่องมือสำหรับนักพัฒนาเว็บเป็นเว็บแอปพลิเคชัน ด้วยเหตุนี้จึงทำโปรไฟล์ได้โดยใช้แผงประสิทธิภาพ หากต้องการเปิดโปรไฟล์ของแผงนี้ คุณสามารถเปิดเครื่องมือสำหรับนักพัฒนาเว็บ จากนั้นเปิดอินสแตนซ์เครื่องมือสำหรับนักพัฒนาเว็บอื่นที่แนบมากับแผงนี้ได้ ที่ Google การตั้งค่านี้เรียกว่าเครื่องมือสำหรับนักพัฒนาเว็บ
เมื่อพร้อมตั้งค่าแล้ว สถานการณ์ที่ต้องสร้างโปรไฟล์จะต้องถูกสร้างและบันทึกอีกครั้ง เราเรียกหน้าต่างเครื่องมือสำหรับนักพัฒนาเว็บเดิมว่า "อินสแตนซ์เครื่องมือสำหรับนักพัฒนาเว็บแรก" และหน้าต่างที่ตรวจสอบอินสแตนซ์แรกจะเรียกว่า "อินสแตนซ์เครื่องมือสำหรับนักพัฒนาเว็บรอง"
![ภาพหน้าจอของอินสแตนซ์เครื่องมือสำหรับนักพัฒนาเว็บที่ตรวจสอบองค์ประกอบในเครื่องมือสําหรับนักพัฒนาเว็บเอง](https://developer.chrome.com/static/blog/perf-panel-4x-faster/image/fig-1.png?authuser=6&hl=th)
ในอินสแตนซ์ที่ 2 ของเครื่องมือสำหรับนักพัฒนาเว็บ แผงประสิทธิภาพซึ่งจะเรียกว่าแผงประสิทธิภาพนับจากนี้เป็นต้นไป จะสังเกตอินสแตนซ์แรกของเครื่องมือสำหรับนักพัฒนาเว็บเพื่อสร้างสถานการณ์จำลอง ซึ่งจะโหลดโปรไฟล์ขึ้นมา
ในอินสแตนซ์ที่ 2 ของเครื่องมือสำหรับนักพัฒนาเว็บจะเริ่มต้นการบันทึกสด ขณะที่ในอินสแตนซ์แรก โปรไฟล์จะโหลดจากไฟล์ในดิสก์ ระบบจะโหลดไฟล์ขนาดใหญ่เพื่อรักษาประสิทธิภาพของการประมวลผลอินพุตขนาดใหญ่ได้อย่างแม่นยำ เมื่อโหลดทั้ง 2 อินสแตนซ์เสร็จแล้ว ข้อมูลการสร้างโปรไฟล์ประสิทธิภาพ (หรือที่เรียกว่าtrace) จะแสดงในอินสแตนซ์ที่ 2 ของ DevTools ของแผงประสิทธิภาพที่โหลดโปรไฟล์
สถานะเริ่มต้น: ระบุโอกาสในการปรับปรุง
หลังจากที่โหลดเสร็จแล้ว ระบบสังเกตการณ์ต่อไปนี้ในอินสแตนซ์ของแผง Perf ที่ 2 ในภาพหน้าจอถัดไป โฟกัสที่กิจกรรมของเทรดหลัก ซึ่งจะปรากฏภายใต้แทร็กที่ติดป้ายกำกับหลัก จะเห็นได้ว่ามีกิจกรรม 5 กลุ่มใหญ่ในแผนภูมิเปลวไฟ งานเหล่านี้จะประกอบด้วยงานที่การโหลดใช้เวลามากที่สุด เวลารวมของงานเหล่านี้คือประมาณ 10 วินาที ในภาพหน้าจอต่อไปนี้ แผงประสิทธิภาพจะใช้เพื่อโฟกัสที่กลุ่มกิจกรรมแต่ละกลุ่มเพื่อดูว่าจะพบอะไรบ้าง
![ภาพหน้าจอของแผงประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บที่ตรวจสอบการโหลดการติดตามประสิทธิภาพในแผงประสิทธิภาพของอินสแตนซ์เครื่องมือสำหรับนักพัฒนาเว็บอื่น โปรไฟล์จะใช้เวลาประมาณ 10 วินาทีในการโหลด ซึ่งเวลานี้ส่วนใหญ่จะแบ่งกิจกรรมออกเป็น 5 กลุ่มหลัก](https://developer.chrome.com/static/blog/perf-panel-4x-faster/image/fig-2.png?authuser=6&hl=th)
กลุ่มกิจกรรมแรก: งานที่ไม่จำเป็น
เห็นได้ชัดว่ากิจกรรมกลุ่มแรกเป็นโค้ดเดิมที่ยังคงทำงานอยู่ แต่ไม่จำเป็นจริงๆ พูดง่ายๆ ก็คือ ทุกอย่างที่อยู่ด้านล่างบล็อกสีเขียวที่มีป้ายกำกับว่า processThreadEvents
ช่างเสียเปล่า ข้อนั้นถือว่าชนะเร็วๆ เลย การนำการเรียกใช้ฟังก์ชันดังกล่าวออกช่วยให้ประหยัดเวลาได้ประมาณ 1.5 วินาที เจ๋ง
กลุ่มกิจกรรมที่ 2
โซลูชันในกลุ่มกิจกรรมที่ 2 ไม่ได้ง่ายเหมือนกลุ่มแรก buildProfileCalls
ใช้เวลาประมาณ 0.5 วินาที และงานดังกล่าวก็ไม่ใช่สิ่งที่หลีกเลี่ยงได้
![ภาพหน้าจอของแผงประสิทธิภาพในเครื่องมือสําหรับนักพัฒนาเว็บที่ตรวจสอบอินสแตนซ์ของแผงประสิทธิภาพอื่น งานที่เชื่อมโยงกับฟังก์ชัน createProfileCalls จะใช้เวลาประมาณ 0.5 วินาที](https://developer.chrome.com/static/blog/perf-panel-4x-faster/image/fig-3.png?authuser=6&hl=th)
ด้วยความสงสัย เราจึงเปิดใช้ตัวเลือกหน่วยความจำในแผงประสิทธิภาพเพื่อตรวจสอบเพิ่มเติม และพบว่ากิจกรรม buildProfileCalls
ก็ใช้หน่วยความจำจำนวนมากเช่นกัน จากตรงนี้ คุณจะเห็นว่ากราฟเส้นสีน้ำเงินพุ่งขึ้นกะทันหันอย่างไรในช่วงเวลาที่ buildProfileCalls
ซึ่งชี้ให้เห็นว่าหน่วยความจำอาจรั่วไหล
![ภาพหน้าจอของเครื่องมือสร้างโปรไฟล์หน่วยความจำในเครื่องมือสำหรับนักพัฒนาเว็บที่ประเมินการใช้หน่วยความจำของแผงประสิทธิภาพ เครื่องมือตรวจสอบชี้ให้เห็นว่าฟังก์ชัน createProfileCalls เป็นสาเหตุของการรั่วไหลของหน่วยความจำ](https://developer.chrome.com/static/blog/perf-panel-4x-faster/image/fig-4.png?authuser=6&hl=th)
เราใช้แผง Memory (แผงอื่นในเครื่องมือสำหรับนักพัฒนาเว็บ ซึ่งต่างจากลิ้นชัก "หน่วยความจำ" ในแผง Perf) ในการตรวจสอบ ภายในแผงหน่วยความจำ มีการเลือกประเภทการทำโปรไฟล์ "การสุ่มตัวอย่างการจัดสรร" ซึ่งจะบันทึกสแนปชอตฮีปสำหรับแผงประสิทธิภาพที่โหลดโปรไฟล์ CPU
![ภาพหน้าจอของสถานะเริ่มต้นของเครื่องมือสร้างโปรไฟล์หน่วยความจำ ตัวเลือก "การสุ่มตัวอย่างการจัดสรร" จะถูกไฮไลต์ด้วยช่องสีแดง และระบุว่าตัวเลือกนี้เหมาะสำหรับการทำโปรไฟล์หน่วยความจำของ JavaScript](https://developer.chrome.com/static/blog/perf-panel-4x-faster/image/fig-5.png?authuser=6&hl=th)
ภาพหน้าจอต่อไปนี้แสดงฮีพสแนปชอตที่รวบรวม
![ภาพหน้าจอของเครื่องมือสร้างโปรไฟล์หน่วยความจำที่เลือกการดำเนินการตามการตั้งค่าที่ใช้หน่วยความจำมาก](https://developer.chrome.com/static/blog/perf-panel-4x-faster/image/fig-6.png?authuser=6&hl=th)
จากฮีพสแนปชอตนี้ เราพบว่าคลาส Set
ใช้หน่วยความจำจำนวนมาก จากการตรวจสอบจุดเรียกพบว่าเรากำหนดพร็อพเพอร์ตี้ประเภท Set
ให้กับออบเจ็กต์ที่สร้างขึ้นในปริมาณมากโดยไม่จำเป็น ค่าใช้จ่ายนี้เพิ่มขึ้นเรื่อยๆ และใช้หน่วยความจำเป็นจำนวนมากจนถึงขั้นทั่วไปที่แอปพลิเคชันขัดข้องในอินพุตขนาดใหญ่
ชุดมีประโยชน์สำหรับการจัดเก็บรายการที่ไม่ซ้ำกันและมอบการดำเนินการที่ใช้ความเป็นเอกลักษณ์ของเนื้อหา เช่น การทำซ้ำชุดข้อมูล และให้การค้นหาที่มีประสิทธิภาพยิ่งขึ้น อย่างไรก็ตาม ฟีเจอร์เหล่านั้นไม่จําเป็น เนื่องจากข้อมูลที่จัดเก็บไว้จะไม่ซ้ำกันจากแหล่งที่มา ดังนั้นจึงไม่จําเป็นต้องใช้เซ็ตตั้งแต่แรก เพื่อปรับปรุงการจัดสรรหน่วยความจำ ระบบได้เปลี่ยนประเภทพร็อพเพอร์ตี้จาก Set
เป็นอาร์เรย์ธรรมดา หลังจากใช้การเปลี่ยนแปลงนี้ ระบบได้บันทึกฮีพสแนปชอตอื่นและสังเกตการจัดสรรหน่วยความจำที่ลดลง แม้ว่าจะไม่สามารถปรับปรุงความเร็วได้อย่างมากจากการเปลี่ยนแปลงนี้ แต่ประโยชน์ที่สองคือแอปพลิเคชันขัดข้องน้อยลง
![ภาพหน้าจอของเครื่องมือสร้างโปรไฟล์หน่วยความจำ การดำเนินการแบบ "ตั้งค่า" ที่ใช้หน่วยความจำก่อนหน้านี้ได้เปลี่ยนเป็นใช้อาร์เรย์ธรรมดา ซึ่งช่วยลดค่าใช้จ่ายของหน่วยความจำลงได้อย่างมาก](https://developer.chrome.com/static/blog/perf-panel-4x-faster/image/fig-7.png?authuser=6&hl=th)
กลุ่มกิจกรรมที่ 3: ข้อดีข้อเสียของโครงสร้างข้อมูลในการชั่งน้ำหนัก
ส่วนที่ 3 นั้นดูแปลกๆ คุณจะเห็นในแผนภูมิเปลวไฟว่าประกอบด้วยคอลัมน์แคบๆ แต่สูง ซึ่งแสดงการเรียกใช้ฟังก์ชันลึก และการทำซ้ำแบบเจาะลึกในกรณีนี้ โดยรวมแล้ว ส่วนนี้ใช้เวลาประมาณ 1.4 วินาที เมื่อดูที่ด้านล่างของส่วนนี้ เราพบว่าความกว้างของคอลัมน์เหล่านี้กำหนดโดยระยะเวลาของฟังก์ชัน appendEventAtLevel
ซึ่งชี้ให้เห็นว่าอาจเป็นจุดคอขวด
เมื่อใช้งานฟังก์ชัน appendEventAtLevel
มี 1 อย่างที่โดดเด่น สำหรับทุกๆ ข้อมูลที่ป้อนในอินพุต (ซึ่งในโค้ดเรียกว่า "เหตุการณ์") จะมีการเพิ่มรายการลงในแผนที่ที่ติดตามตำแหน่งแนวตั้งของรายการในไทม์ไลน์ ซึ่งเป็นปัญหาเนื่องจากจำนวนรายการที่เก็บนั้นมีจำนวนมาก 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);
// ...
}
เราลองใช้วิธีอื่นที่ไม่ได้กำหนดให้เราต้องเพิ่มไอเทมในแผนที่สำหรับทุกรายการใน Fle Chart การปรับปรุงนั้นสำคัญมาก โดยยืนยันว่าจุดคอขวดนั้นเกี่ยวข้องกับค่าใช้จ่ายที่เกิดขึ้นจริงๆ ด้วยการเพิ่มข้อมูลทั้งหมดลงในแผนที่ เวลาที่กลุ่มกิจกรรมลดลงจากประมาณ 1.4 วินาทีเป็นประมาณ 200 มิลลิวินาที
ก่อน
![ภาพหน้าจอของแผงประสิทธิภาพก่อนที่จะมีการเพิ่มประสิทธิภาพในฟังก์ชัน appendEventAtLevel เวลารวมที่ฟังก์ชันจะทำงานคือ 1,372.51 มิลลิวินาที](https://developer.chrome.com/static/blog/perf-panel-4x-faster/image/fig-9.png?authuser=6&hl=th)
หลัง:
![ภาพหน้าจอของแผงประสิทธิภาพหลังจากการเพิ่มประสิทธิภาพในฟังก์ชัน appendEventAtLevel เวลารวมที่ฟังก์ชันจะทำงานคือ 207.2 มิลลิวินาที](https://developer.chrome.com/static/blog/perf-panel-4x-faster/image/fig-10.png?authuser=6&hl=th)
กลุ่มที่ 4: การเลื่อนข้อมูลงานที่ไม่สำคัญและข้อมูลแคชไว้เพื่อป้องกันงานที่ซ้ำกัน
เมื่อซูมเข้าในหน้าต่างนี้ จะเห็นได้ว่ามีการเรียกฟังก์ชันที่เหมือนกันสองบล็อก เมื่อดูชื่อของฟังก์ชันที่เรียกใช้ คุณจะอนุมานได้ว่าบล็อกเหล่านี้ประกอบด้วยโค้ดที่กําลังสร้างต้นไม้ (เช่น มีชื่ออย่างเช่น refreshTree
หรือ buildChildren
) อันที่จริง โค้ดที่เกี่ยวข้องคือโค้ดที่สร้างมุมมองแบบต้นไม้ในลิ้นชักด้านล่างของแผง สิ่งที่น่าสนใจคือ มุมมองแบบต้นไม้เหล่านี้ไม่ได้แสดงทันทีหลังจากการโหลด โดยผู้ใช้ต้องเลือกมุมมองต้นไม้ (แท็บ "ด้านล่างบน" "โครงสร้างการเรียก" และ "บันทึกเหตุการณ์" ในลิ้นชัก) เพื่อแสดงต้นไม้ นอกจากนี้ อย่างที่คุณสามารถบอกได้จากภาพหน้าจอ ขั้นตอนการสร้างต้นไม้มีการดำเนินการ 2 ครั้ง
![ภาพหน้าจอของแผงประสิทธิภาพที่แสดงงานซ้ำๆ หลายรายการที่ดำเนินการแม้จะไม่จำเป็น งานเหล่านี้อาจถูกเลื่อนเวลาออกไปดำเนินการตามความต้องการ แทนที่จะเป็นการทำงานล่วงหน้า](https://developer.chrome.com/static/blog/perf-panel-4x-faster/image/fig-11.png?authuser=6&hl=th)
มีปัญหาสองประการที่เราพบในภาพนี้:
- งานที่ไม่สำคัญเป็นอุปสรรคต่อประสิทธิภาพของเวลาที่ใช้ในการโหลด ผู้ใช้ไม่จำเป็นต้องมีเอาต์พุตเสมอไป ดังนั้น งานนี้จึงไม่สำคัญต่อการโหลดโปรไฟล์
- ระบบไม่ได้แคชผลลัพธ์ของงานเหล่านี้ ระบบจึงคำนวณต้นไม้ 2 ครั้งแม้ว่าข้อมูลจะไม่มีการเปลี่ยนแปลงก็ตาม
เราเริ่มจากการเลื่อนการคำนวณโครงสร้างไปเป็นเวลาที่ผู้ใช้เปิดมุมมองแบบต้นไม้ด้วยตนเอง ในการสร้างต้นไม้เหล่านี้ก็คุ้มค่ากับความคุ้มค่า เวลารวมในการเรียกใช้ 2 ครั้งคือประมาณ 3.4 วินาที ดังนั้นการยืดเวลาออกไปจึงสร้างความแตกต่างอย่างมากในด้านเวลาที่ใช้ในการโหลด เรายังคงตรวจสอบการแคชงานประเภทนี้อยู่เช่นกัน
กลุ่มกิจกรรมที่ 5: หลีกเลี่ยงลำดับชั้นการเรียกที่ซับซ้อน หากทำได้
เมื่อพิจารณากลุ่มนี้อย่างละเอียดแล้ว ก็เห็นได้ชัดว่ามีการเรียกใช้ห่วงโซ่การโทรหนึ่งๆ ซ้ำๆ รูปแบบเดียวกันปรากฏ 6 ครั้งในที่ต่างๆ ในแผนภูมิเปลวไฟ และระยะเวลารวมของหน้าต่างนี้ประมาณ 2.4 วินาที
![ภาพหน้าจอของแผงประสิทธิภาพที่แสดงการเรียกใช้ฟังก์ชัน 6 รายการสำหรับการสร้างแผนที่ขนาดเล็กการติดตามเดียวกัน โดยแต่ละรายการมีสแต็กการเรียกใช้ Deep](https://developer.chrome.com/static/blog/perf-panel-4x-faster/image/fig-12.png?authuser=6&hl=th)
โค้ดที่เกี่ยวข้องที่มีการเรียกหลายครั้งคือส่วนที่ประมวลผลข้อมูลเพื่อแสดงใน "แผนที่ขนาดเล็ก" (ภาพรวมของกิจกรรมในไทม์ไลน์ที่ด้านบนสุดของแผง) เราไม่ทราบสาเหตุที่แน่ชัดว่าเหตุการณ์นี้เกิดขึ้นหลายครั้ง แต่ไม่จำเป็นต้องเกิดขึ้นซ้ำถึง 6 ครั้ง ที่จริงแล้ว เอาต์พุตของโค้ดควรเป็นปัจจุบันต่อไปหากไม่ได้โหลดโปรไฟล์อื่นไว้ ในทางทฤษฎี โค้ดควรทำงานเพียงครั้งเดียว
จากการตรวจสอบพบว่ามีการเรียกใช้โค้ดที่เกี่ยวข้องอันเป็นผลมาจากหลายส่วนในไปป์ไลน์การโหลดที่เรียกฟังก์ชันที่คำนวณแผนที่ขนาดเล็กนั้นโดยตรงหรือโดยอ้อม เนื่องจากความซับซ้อนของกราฟการโทรของโปรแกรมได้เปลี่ยนแปลงไปเมื่อเวลาผ่านไป และมีการเพิ่มทรัพยากร Dependency ให้กับโค้ดนี้โดยไม่รู้ตัว ปัญหานี้ไม่มีวิธีแก้ไขด่วน วิธีแก้ปัญหาจะขึ้นอยู่กับสถาปัตยกรรมของฐานของโค้ดที่เป็นปัญหา ในกรณีของเรา เราต้องลดความซับซ้อนของลำดับชั้นการเรียกลงเล็กน้อยและเพิ่มการตรวจสอบเพื่อป้องกันการดำเนินการของโค้ดหากข้อมูลอินพุตยังคงเดิม หลังจากที่นำโค้ดนี้ไปใช้แล้ว เราได้การคาดการณ์ไทม์ไลน์ดังนี้
![ภาพหน้าจอของแผงประสิทธิภาพที่แสดงการเรียกใช้ฟังก์ชัน 6 รายการแยกกันสำหรับการสร้างแผนที่ขนาดเล็กการติดตามเดียวกันลดลงเหลือเพียง 2 ครั้ง](https://developer.chrome.com/static/blog/perf-panel-4x-faster/image/fig-13.png?authuser=6&hl=th)
โปรดทราบว่าการแสดงผลแผนที่ขนาดเล็กจะเกิดขึ้น 2 ครั้ง ไม่ใช่ 1 ครั้ง เพราะมีการวาดแผนที่ขนาดเล็ก 2 แผนที่สำหรับทุกโปรไฟล์ นั่นคือ รูปหนึ่งสำหรับภาพรวมที่ด้านบนของแผง และอีกแผนที่หนึ่งสำหรับเมนูแบบเลื่อนลงที่เลือกโปรไฟล์ที่มองเห็นได้ในปัจจุบันจากประวัติ (ทุกรายการในเมนูนี้มีภาพรวมของโปรไฟล์ที่เลือก) อย่างไรก็ตาม ทั้ง 2 อย่างนี้มีเนื้อหาเดียวกัน จึงควรใช้วิดีโอใดเนื้อหาหนึ่งซ้ำสำหรับอีกวิดีโอหนึ่งได้
เนื่องจากแผนที่ขนาดเล็กเหล่านี้เป็นภาพที่วาดบนผืนผ้าใบ จึงเป็นการใช้ยูทิลิตีของ Canvas ของ drawImage
และจากนั้นให้เรียกใช้โค้ดเพียงครั้งเดียวเพื่อประหยัดเวลา ความพยายามนี้ส่งผลให้ระยะเวลาของกลุ่มลดลงจาก 2.4 วินาทีเป็น 140 มิลลิวินาที
บทสรุป
หลังจากใช้การแก้ไขเหล่านี้ทั้งหมดแล้ว (และการแก้ไขเล็กๆ น้อยๆ อีก 2-3 รายการ) การเปลี่ยนแปลงลำดับเวลาการโหลดโปรไฟล์มีดังนี้
ก่อน
![ภาพหน้าจอของแผงประสิทธิภาพที่แสดงการโหลดการติดตามก่อนการเพิ่มประสิทธิภาพ กระบวนการนี้ใช้เวลาประมาณ 10 วินาที](https://developer.chrome.com/static/blog/perf-panel-4x-faster/image/fig-14.png?authuser=6&hl=th)
หลัง:
![ภาพหน้าจอของแผงประสิทธิภาพที่แสดงการโหลดการติดตามหลังจากการเพิ่มประสิทธิภาพ ขั้นตอนนี้จะใช้เวลาประมาณ 2 วินาที](https://developer.chrome.com/static/blog/perf-panel-4x-faster/image/fig-15.png?authuser=6&hl=th)
ใช้เวลาโหลดหลังจากการปรับปรุง 2 วินาที ซึ่งหมายความว่ามีการปรับปรุงประมาณ 80% โดยใช้ความพยายามค่อนข้างต่ำ เนื่องจากการดำเนินการส่วนใหญ่ที่ทำเสร็จประกอบด้วยการแก้ไขอย่างรวดเร็ว แน่นอนว่าการระบุสิ่งที่ต้องทำในช่วงแรกอย่างเหมาะสมคือกุญแจสำคัญ และแผงประสิทธิภาพเป็นเครื่องมือที่เหมาะสำหรับขั้นตอนนี้
สิ่งสำคัญอีกอย่างที่ควรทราบคือตัวเลขเหล่านี้ใช้เฉพาะกับโปรไฟล์ที่ใช้เป็นวิชาในการศึกษา โปรไฟล์นี้น่าสนใจเพราะค่อนข้างใหญ่ อย่างไรก็ตาม เนื่องจากไปป์ไลน์การประมวลผลเหมือนกันในทุกโปรไฟล์ การปรับปรุงที่สำคัญจึงจะมีผลกับทุกโปรไฟล์ที่โหลดในแผงประสิทธิภาพ
แย่งลูกกลับมา
การเพิ่มประสิทธิภาพการทำงานของแอปพลิเคชันของคุณอาจเกิดจากบทเรียนต่อไปนี้
1. ใช้ประโยชน์จากเครื่องมือการทำโปรไฟล์เพื่อระบุรูปแบบประสิทธิภาพของรันไทม์
เครื่องมือสร้างโปรไฟล์มีประโยชน์อย่างยิ่งในการทำความเข้าใจสิ่งที่เกิดขึ้นในแอปพลิเคชันของคุณขณะทำงาน โดยเฉพาะอย่างยิ่งเพื่อระบุโอกาสในการปรับปรุงประสิทธิภาพ แผงประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome เป็นตัวเลือกที่ยอดเยี่ยมสำหรับเว็บแอปพลิเคชัน เนื่องจากเป็นเครื่องมือทำโปรไฟล์เว็บแบบเนทีฟในเบราว์เซอร์ และมีการรักษาให้เป็นปัจจุบันอยู่เสมอด้วยฟีเจอร์แพลตฟอร์มเว็บล่าสุด และปัจจุบันเร็วขึ้นมากด้วย 😉
ใช้ตัวอย่างที่สามารถนำไปใช้เป็นภาระงานที่เป็นตัวแทนและดูสิ่งที่คุณค้นหาได้
2. หลีกเลี่ยงลําดับชั้นการโทรที่ซับซ้อน
หากเป็นไปได้ โปรดหลีกเลี่ยงการสร้างกราฟที่มีความซับซ้อนมากเกินไป ด้วยลำดับชั้นของการเรียกใช้ที่ซับซ้อน การทำให้เกิดการถดถอยด้านประสิทธิภาพจึงเป็นเรื่องง่ายและเข้าใจได้ยากว่าเหตุใดโค้ดของคุณจึงทำงานอย่างที่เป็นอยู่ ซึ่งทำให้ทำการปรับปรุงได้ยาก
3. ระบุงานที่ไม่จำเป็น
เป็นเรื่องปกติที่โค้ดเบสเก่าจะมีโค้ดที่ไม่จำเป็นอีกต่อไป ในกรณีของเรา โค้ดแบบเดิมและโค้ดที่ไม่จำเป็นกินเวลาการโหลดทั้งหมดอย่างมาก การนำทิ้งดังกล่าวออกเป็นผลไม้ที่หายาก
4. ใช้โครงสร้างข้อมูลอย่างเหมาะสม
ใช้โครงสร้างข้อมูลเพื่อเพิ่มประสิทธิภาพ แต่ทำความเข้าใจค่าใช้จ่ายและข้อดีข้อเสียของโครงสร้างข้อมูลแต่ละประเภทเมื่อตัดสินใจว่าจะใช้โครงสร้างใด ซึ่งไม่ได้มีเพียงแค่ความซับซ้อนด้านพื้นที่ของโครงสร้างข้อมูลเท่านั้น แต่ยังรวมถึงความซับซ้อนด้านเวลาของการดำเนินงานที่เกี่ยวข้องด้วย
5. แคชผลลัพธ์เพื่อหลีกเลี่ยงงานที่ซ้ำกันสำหรับการดำเนินการที่ซับซ้อนหรือซ้ำซ้อน
หากการดำเนินการนั้นมีค่าใช้จ่ายสูง ก็เหมาะที่จะเก็บผลลัพธ์ไว้สำหรับครั้งต่อไปที่จำเป็น นอกจากนี้ คุณควรดำเนินการนี้ในกรณีที่การดำเนินการนั้นเสร็จสิ้นหลายครั้ง แม้ว่าแต่ละครั้งจะไม่ได้เสียค่าใช้จ่ายมากนักก็ตาม
6. เลื่อนเวลางานที่ไม่สำคัญ
หากไม่จำเป็นต้องใช้เอาต์พุตของงานในทันที และการดำเนินการของงานขยายเส้นทางวิกฤติ ให้พิจารณาเลื่อนเวลาการทำงานออกไปด้วยการเรียกใช้แบบ Lazy Loading เมื่อระบบต้องการเอาต์พุตจริงๆ
7. ใช้อัลกอริทึมที่มีประสิทธิภาพกับอินพุตขนาดใหญ่
สำหรับอินพุตข้อมูลขนาดใหญ่ อัลกอริทึมความซับซ้อนของเวลาที่เหมาะสมจะกลายเป็นสิ่งสำคัญ เราไม่ได้พิจารณาหมวดหมู่นี้ในตัวอย่างนี้ แต่ความสำคัญของหมวดหมู่เหล่านี้แทบจะพูดเกินจริงไม่ได้เลย
8. โบนัส: เปรียบเทียบไปป์ไลน์
เพื่อให้มั่นใจว่าโค้ดที่เปลี่ยนแปลงอย่างต่อเนื่องนั้นเร็วอยู่เสมอ คุณควรตรวจสอบการทำงานและเปรียบเทียบกับมาตรฐาน วิธีนี้จะทำให้คุณระบุการถดถอยและปรับปรุงความน่าเชื่อถือโดยรวมในเชิงรุกได้ และช่วยให้คุณประสบความสำเร็จในระยะยาว