ขีดจำกัดหน่วยความจำของเบราว์เซอร์เวลาประมวลผลไฟล์
ไฟล์แค่ 15 MB เอง ทำไมแท็บถึงหน่วยความจำหมด
ไฟล์บนดิสก์คือเวอร์ชันที่ถูกบีบอัดไว้
ความเข้าใจผิดทั้งหมดสรุปได้ในประโยคเดียว คือตัวเลขที่คุณเห็นในโปรแกรมจัดการไฟล์คือขนาดของข้อมูลที่บีบอัดแล้ว และไม่มีอะไรประมวลผลได้ขณะที่ยังถูกบีบอัดอยู่ การจะย่อขนาด บีบอัดใหม่ แปลง หรือวิเคราะห์ภาพ ต้องถอดรหัสมันออกมาเป็นพิกเซลดิบก่อน และพิกเซลดิบนั้นใหญ่มหาศาล
เลขคณิตนั้นง่ายมาก พิกเซลหนึ่งพิกเซลในหน่วยความจำปกติกินสี่ไบต์ คือแดง เขียว น้ำเงิน และอัลฟา ภาพถ่ายขนาด 4000 × 3000 มีสิบสองล้านพิกเซล บิตแมปที่ถอดรหัสแล้วจึงมีขนาดราว 48 MB ในขณะที่ไฟล์ JPEG ต้นทางอาจมีแค่ 4 MB ไฟล์โตขึ้นสิบสองเท่าก่อนงานจะเริ่มเสียด้วยซ้ำ
| ขนาดภาพ | จำนวนพิกเซล | บิตแมปหลังถอดรหัส |
|---|---|---|
| 1920 × 1080 | 2.1 ล้าน | ราว 8 MB |
| 4000 × 3000 | 12 ล้าน | ราว 48 MB |
| 6000 × 4000 | 24 ล้าน | ราว 96 MB |
| 10000 × 10000 | 100 ล้าน | ราว 400 MB |
และสำเนาเดียวไม่เคยพอ
กระบวนการทำงานจริงถือหลายสำเนาไว้พร้อมกัน ทั้งไบต์อินพุตที่ยังบีบอัดอยู่ บิตแมปต้นทางที่ถอดรหัสแล้ว บิตแมปผลลัพธ์ที่ขนาดใหม่ บัฟเฟอร์ภายในของตัวเข้ารหัส และผลลัพธ์ที่บีบอัดแล้ว เครื่องมือที่แสดงภาพตัวอย่างให้ดูด้วยก็ถือเพิ่มอีกหนึ่งสำเนา สำหรับภาพถ่าย 4000 × 3000 ข้างต้น การใช้หน่วยความจำสูงสุดที่สองถึงสามร้อยเมกะไบต์ถือเป็นเรื่องปกติทุกประการ สำหรับไฟล์ที่ดูเหมือนมีแค่ 4 MB
การแปลง PDF เป็นแรสเตอร์ก็เป็นแบบเดียวกันในระดับหน้าต่อหน้า หน้ากระดาษ A4 ที่เรนเดอร์ที่ 300 DPI มีขนาดราว 2480 × 3508 พิกเซล หรือราว 35 MB หลังถอดรหัส และเครื่องมือที่เรนเดอร์หลายหน้าพร้อมกันก็คูณตัวเลขนั้นขึ้นไปอีก ส่วนวิดีโอหนักกว่านั้นอีก เพราะตัวถอดรหัสต้องคงเฟรมอ้างอิงหลายเฟรมไว้ในหน่วยความจำพร้อมกัน
เพดานจริง ๆ อยู่ตรงไหน
- งบหน่วยความจำของแท็บถูกกำหนดโดยเบราว์เซอร์ ไม่ใช่โดยเว็บไซต์ และมันน้อยกว่าหน่วยความจำที่ติดตั้งอยู่ในเครื่อง อีกทั้งยังหดลงอีกเมื่อแท็บอื่นกำลังทำงานหนัก
- โมดูล WebAssembly ที่สร้างด้วยโมเดลหน่วยความจำ 32 บิตซึ่งใช้กันทั่วไป อ้างถึงหน่วยความจำได้มากที่สุดสี่กิบิไบต์ และเบราว์เซอร์มักอนุญาตให้น้อยกว่านั้นมากต่อหนึ่งอินสแตนซ์
- บัฟเฟอร์แต่ละก้อนมีความยาวสูงสุดของตัวเอง ซึ่งต่ำกว่าหน่วยความจำรวมที่หน้าเว็บอาจใช้ได้อยู่มาก
- ระบบปฏิบัติการบนมือถือจะปิดแท็บที่โตเกินไปทิ้ง โดยไม่มีคำเตือนและไม่มีข้อผิดพลาดใดที่หน้าเว็บดักจับได้
- หน่วยความจำกราฟิกเป็นพูลแยกต่างหากและเล็กกว่า Canvas ที่ใหญ่เกินขนาดสูงสุดของแพลตฟอร์มจะล้มเหลวไปเลย ไม่ว่าหน่วยความจำระบบจะเหลือมากแค่ไหน
ไม่มีข้อไหนถูกประกาศเป็นตัวเลขเดียวที่เปิดดูได้ เพราะทั้งหมดขึ้นอยู่กับเบราว์เซอร์ เวอร์ชัน อุปกรณ์ และสิ่งอื่นที่กำลังทำงานอยู่ นั่นคือความยากที่แท้จริง เพราะเครื่องมือถามไม่ได้ว่ามันใช้หน่วยความจำได้เท่าไร
ทำไมมือถือถึงเป็นกรณีที่เข้มงวดที่สุด
มือถือมีหน่วยความจำจริงน้อยกว่า ไม่มีพื้นที่สลับหน่วยความจำในความหมายแบบเดสก์ท็อป และมีระบบปฏิบัติการที่ดุดันในการทวงหน่วยความจำคืนจากโพรเซสเบื้องหลัง แท็บเบราว์เซอร์กลายเป็นโพรเซสเบื้องหลังทันทีที่คุณตอบข้อความ เบราว์เซอร์บนมือถือจึงตั้งงบไว้รัดกุมกว่าและทิ้งแท็บเร็วกว่า และการทิ้งแท็บนั้นในสายตาคุณมักดูเหมือนหน้าเว็บโหลดใหม่แล้วงานที่ทำค้างไว้หายไป มากกว่าจะดูเหมือนข้อผิดพลาด
ผลในทางปฏิบัติคืองานที่ทำจนจบได้บนโน้ตบุ๊กอาจเป็นไปไม่ได้เลยบนมือถือด้วยไฟล์เดียวกัน นั่นไม่ใช่ข้อบกพร่องของเครื่องมือ แต่เป็นขอบเขตของฮาร์ดแวร์ และการตอบสนองที่ซื่อตรงคือบอกให้รู้ก่อนเริ่ม แทนที่จะพังกลางทาง
เครื่องมือที่รอบคอบทำตัวอย่างไร
- มันประเมินหน่วยความจำที่ต้องใช้จากขนาดภาพหลังถอดรหัสก่อนจะจองอะไรทั้งสิ้น และปฏิเสธงานที่เห็นชัดว่าไม่พอดีแน่นอน
- มันประมวลผลทีละไฟล์บนอุปกรณ์ที่มีทรัพยากรจำกัด แทนที่จะรันเป็นชุดพร้อมกัน
- มันโอนบัฟเฟอร์ระหว่างหน้าเว็บกับเวิร์กเกอร์แทนการคัดลอก ไฟล์ขนาดใหญ่จึงไม่ถูกเก็บซ้ำสองชุด
- มันปล่อยผลลัพธ์แต่ละชิ้นทันทีที่เขียนเสร็จ และเพิกถอน URL ชั่วคราวที่ไม่เช่นนั้นจะทำให้ข้อมูลค้างอยู่ในหน่วยความจำ
- มันประมวลผลแบบสตรีมทีละหน้าหรือทีละเฟรมในกรณีที่ฟอร์แมตเอื้อ แทนที่จะโหลดทั้งเอกสารเข้าหน่วยความจำ
- มันจำกัดจำนวนพิกเซลที่ยอมรับ ซึ่งเป็นสิ่งเดียวกับที่กันไม่ให้ไฟล์เล็ก ๆ ที่ขยายออกเป็น Canvas ขนาดมหึมามาทำให้แท็บล่ม
ทำอะไรได้บ้างเมื่องานล้มเหลว
- ปิดแท็บอื่น ๆ มันกำลังแย่งงบก้อนเดียวกันอยู่ และเบราว์เซอร์ไม่ได้แบ่งงบนั้นอย่างยุติธรรม
- ประมวลผลไฟล์ให้น้อยลงต่อครั้ง คิวที่มีไฟล์เดียวช้ากว่าก็จริง แต่มีโอกาสทำจนจบสูงกว่ามาก
- ลดขนาดภาพก่อน การลดด้านที่ยาวที่สุดลงครึ่งหนึ่งทำให้หน่วยความจำที่ต้องใช้เหลือหนึ่งในสี่ และมักเป็นสิ่งที่คุณต้องการอยู่แล้ว
- แยก PDF ขนาดใหญ่ออกเป็นส่วน ๆ แล้วประมวลผลทีละส่วน
- ย้ายไปทำงานที่ใหญ่ที่สุดบนเครื่องเดสก์ท็อป นี่ไม่ใช่ความล้มเหลวของการประมวลผลในเครื่อง แต่คือการใช้ฮาร์ดแวร์ที่คุณมีอย่างถูกต้อง
- รีสตาร์ตเบราว์เซอร์หากแท็บถูกเปิดค้างไว้หลายวัน แท็บที่อยู่ยาวจะสะสมหน่วยความจำที่การโหลดใหม่จะคืนให้
ขีดจำกัดของการประมาณการใด ๆ
เบราว์เซอร์เปิดเผยเพียงคำใบ้หยาบ ๆ เกี่ยวกับหน่วยความจำที่ว่างอยู่ และบางตัวไม่เปิดเผยอะไรเลย ตัวเลขใดก็ตามที่เครื่องมือในเครื่องแสดงให้คุณเห็นจึงเป็นการประมาณการที่สร้างจากขนาดของไฟล์เองบวกกับแบบจำลองกระบวนการทำงานแบบระมัดระวัง ไม่ใช่ค่าที่อ่านมาจากระบบปฏิบัติการ มันมีประโยชน์สำหรับตัดสินใจว่าจะลองทำงานนั้นหรือไม่ แต่ไม่ใช่คำรับประกันว่างานจะสำเร็จ เพราะปัจจัยชี้ขาดซึ่งก็คือสิ่งที่ส่วนอื่นของอุปกรณ์จะทำในสามสิบวินาทีข้างหน้า ไม่ใช่สิ่งที่หน้าเว็บมองเห็นได้
เครื่องมือสำหรับเรื่องนี้
แหล่งอ้างอิง
- W3C — WebAssembly Core Specification, memory model
- W3C — Device Memory API, and why the value is coarse
- WHATWG — HTML Standard, transferable objects