คอขวดของความเร็วในการท่องเว็บบนราสเบอร์รี่ไพอยู่ที่ไหน


23

สำหรับรุ่น B 512 MB Pi กับ "Wheezy" ของ Raspbian ฉันได้ลอง Midori, Chromium และ Iceweasel แล้ว เมื่อเว็บเพจมีขนาดใหญ่ขึ้นการโหลดช้าแม้หลังจากโอเวอร์คล็อกไปที่ 1 GHz บนโทรศัพท์ Android ที่มี CPU 1 GHz หน้าเว็บโหลดเร็วกว่ามาก

สิ่งที่ฉันอยากรู้คือขวดคอขวดอยู่ที่ไหน มันเป็นซีพียูหรือขนาด RAM หรือเซิร์ฟเวอร์ X ที่ไม่ทำงานหรือไม่ เป็นไปได้ไหมที่เบราว์เซอร์จะใช้ GPU โดยตรงเพื่อเร่งความเร็ว


และไพกำลังขับหน้าจอขนาด 3.5 "480 x 800
?;

จอภาพ VGA ถูกนำมาใช้สำหรับการแสดงผลผ่านสาย HDMI ต่อ VGA และการตั้งค่าเป็นhdmi_mode=35 1280x1024 60Hz... แต่ฉันไม่สามารถเห็นใด ๆ ดีขึ้นหลังจากการเปลี่ยนแปลงการตั้งค่าไปhdmi_mode=9 800x600 60Hz
hello.wjx

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

คำตอบ:


15

เป็นการผสมผสานระหว่างซีพียู ARM11 ที่ค่อนข้างอ่อนแอของราสเบอร์รี่ Pi กับเซิร์ฟเวอร์ X ที่ไม่มีการเร่งความเร็ว เนื่องจาก GPU ไม่ได้เร่งความเร็ว CPU จึงต้องทำการเรนเดอร์ทั้งหมด ในบางสิ่งบางอย่างเช่น ARM11 core ใน Pi สิ่งนี้ทำให้เครียดมากเป็นพิเศษกับ CPU ที่อ่อนแออยู่แล้ว

โดยทั่วไปในขณะที่ดูhtopในขณะที่ Midori บน Pi โหลดเว็บไซต์ที่หนักหน่วงเช่น Facebook ฉันได้เห็นกระบวนการ X ใช้ CPU ถึง 25%

มันไม่ยุติธรรมเลยที่จะเปรียบเทียบชิปในโทรศัพท์ Android ของคุณกับชิป (แม้แต่โอเวอร์คล็อก) ใน Pi ชิพ 1 GHz ในโทรศัพท์ของคุณน่าจะเป็น Cortex-A8 หรือ A9 ซึ่งใช้สถาปัตยกรรม ARMv7 ดังนั้นจึงมีประสิทธิภาพสูงกว่าต่อรอบสัญญาณนาฬิกามากกว่า ARM11 ซึ่งใช้ ARMv6


GPU เร่งความเร็วในการวาดรูปแบบใดได้บ้าง
Trismegistos

@Trismegistos การเติมภูมิภาคด้วยสีสัน รวมเลเยอร์กับพื้นหลังโปร่งใส ปรับขอบตัวอักษรให้เรียบ
Dmitry Grigoryev

14

นี่เป็นคำตอบที่ถูกต้องแล้ว IMO และสิ่งที่ฉันแนะนำไม่อาจสร้างความแตกต่างได้มากนัก แต่อาจมีประโยชน์ที่จะรู้

หากสิ่งที่คุณต้องการทำคือเรียกใช้เบราว์เซอร์คุณไม่จำเป็นต้องเรียกใช้สภาพแวดล้อมเดสก์ท็อปเช่นกัน สร้างไฟล์ที่มีลักษณะ$HOME/.xinitrcดังนี้:

#!/bin/sh

midori

หาก. xinitrc มีอยู่แล้วให้ย้ายชั่วคราวหรือใส่ความคิดเห็นอื่นใด ทีนี้startx(เห็นได้ชัดว่าคุณไม่ควรอยู่ในนั้น - ทำสิ่งนี้จากคอนโซลโดยไม่ต้องใช้ GUI) Voila คุณมีเพียงเบราว์เซอร์ไม่มีเดสก์ท็อป

นั่นช่วยประหยัดหน่วยความจำได้เล็กน้อยแม้ว่าเบราว์เซอร์จะอยู่ไกลจากตัวช้างในห้องและเซิร์ฟเวอร์ Xorg เอง (กำลังทำงานอยู่) นั้นใหญ่กว่าlxde พื้นฐาน (ซึ่งตอนนี้ไม่ทำงาน) หากคุณโหลด RAM มากจนเกินไปซึ่งคุณกำลังใช้ swap อยู่นั่นจะส่งผลต่อประสิทธิภาพ Midori + bare X ข้างต้นใช้พื้นที่น้อยกว่า 100 MB ตามfree:

             total       used       free     shared    buffers     cached
Mem:        448708     242604     206104          0      82660     105156
-/+ buffers/cache:      54788     393920
Swap:       102396          0     102396

448708 - 393920 = 54788/1024 = 53.5 MB

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

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

กล่าวอีกนัยหนึ่งอย่างเหมาะสมที่สุดที่คุณต้องการให้ ram ที่คุณกำหนดให้ไม่เกิน 75% ของสิ่งที่มีอยู่ใน pi และอาจน้อยกว่านั้น หากคุณใช้ LXDE และเริ่มเปิดสิ่งอื่น ๆ คุณอาจเริ่มเข้าใกล้สิ่งนั้นได้อย่างรวดเร็ว


5

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

คุณสามารถลองใช้ธงของ / Chromeium ของ Google Chrome ภายใต้ภายใต้chrome://flagsเพื่อปรับปรุงประสิทธิภาพการค้นหา (ชัดเจน) มีความเป็นบทความอธิบายบางส่วนของธงที่เกี่ยวข้องกับการปฏิบัติงาน ฉันจะพยายามรวบรวมที่นี่:

บังคับให้เร่งความเร็ว GPUด้วยการเปิดใช้งาน "Overrrite Software Rendering List" จะใช้ GPU ในการเรนเดอร์ด้วยค่าใช้จ่ายของสิ่งประดิษฐ์ที่เป็นไปได้แม้ว่าคนขับจะไม่ได้อยู่ในรายการที่ปลอดภัย ฉันไม่รู้ว่ามันใช้งานได้ดีกับ GPU ของ Pi อย่างไร

การประกอบ GPU ในทุกหน้าจะใช้ GPU เพื่อเลื่อนเลเยอร์ทั้งหมด ดังนั้นประสิทธิภาพการเลื่อนควรปรับปรุงในหน้าเว็บที่ไม่มีเลเยอร์ที่เร่งด้วย GPU

หน้าต่างรีเฟรชตามเข็มนาฬิกาจะเป็นอีกคำใบ้หนึ่ง มันจะเรนเดอร์กระเบื้องและแสดงแต่ละรายการทันทีที่พร้อมแทนที่จะรอจนกว่าจะเสร็จสิ้น การแสดงผลจะใช้เวลานานขึ้นเนื่องจากค่าใช้จ่ายที่แนะนำ แต่เนื้อหาจะปรากฏขึ้นเร็วขึ้น

การเรนเดอร์ในเธรดแยกกันจะทำการเรนเดอร์แบบอะซิงโครนัสและรักษาการตอบกลับของอินเทอร์เฟซ คุณสามารถเลื่อนในขณะที่หน้ายังคงแสดงผล

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

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

ยิ่งไปกว่านั้นสวิตช์บรรทัดคำสั่งสามารถใช้เพื่อเพิ่มประสิทธิภาพ Chrome / Chromium ดูรายการสวิตช์บรรทัดคำสั่ง Chromiumสำหรับรายการทั้งหมด

--default-tile-widthและ--default-tile-heightสามารถตั้งค่าให้ตรงกับเสี้ยวของขนาดหน้าจอเพื่อเร่งการเรนเดอร์เริ่มต้นของแต่ละหน้า


ฉันพยายามธงOverride software rendering list, GPU compositing on all pagesและThreaded compositingใน Pi แต่ดูเหมือนไม่มีการปรับปรุงที่เห็นได้ชัด ฉันอีกครั้งลองตั้งค่าสถานะเหล่านั้นบนพีซีดูเหมือนว่าจะไม่มีการปรับปรุงเช่นกัน
hello.wjx

ตรวจสอบให้แน่ใจว่าได้รีสตาร์ท Chrome หลังจากแก้ไขการตั้งค่าสถานะ เพื่อทดสอบOverride software rendering listเปิดการสาธิต WebGL เพื่อทดสอบThreaded compositingลองเลื่อนขณะที่ยังโหลดหน้าใหญ่อยู่
Bengt

จากสิ่งที่ฉันกำลังอ่านอยู่ที่นี่: chromium.org/developers/design-documents/…การใช้ "การเรียบเรียงโดยใช้เธรด" จะไม่ช่วยปี่ - มันมีแกนเดียวเท่านั้น - และอาจทำให้แย่ลงขึ้นอยู่กับความสำคัญ "operat [ing] บนสำเนาของสถานะการเรนเดอร์ปัจจุบัน" คือ
goldilocks

ประสิทธิภาพการโหลดหน้าเว็บจะลดลงใช่ แต่ Javascript จะไม่บล็อกและรอการเรนเดอร์และหน้านั้นจะตอบสนองต่อไป คุณกำลังซื้อขายประสิทธิภาพตามวัตถุประสงค์เพื่อประสิทธิภาพที่รับรู้
Bengt
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.