ข้ามไปยังเนื้อหา
FileSlimmer
เครื่องมือ
คู่มือ

ขีดจำกัดหน่วยความจำของเบราว์เซอร์เวลาประมวลผลไฟล์

ตรวจทานล่าสุด

ไฟล์แค่ 15 MB เอง ทำไมแท็บถึงหน่วยความจำหมด

อ่าน 4 นาที · ตรวจทานเมื่อ 17 สิงหาคม 2569

ไฟล์บนดิสก์คือเวอร์ชันที่ถูกบีบอัดไว้

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

เลขคณิตนั้นง่ายมาก พิกเซลหนึ่งพิกเซลในหน่วยความจำปกติกินสี่ไบต์ คือแดง เขียว น้ำเงิน และอัลฟา ภาพถ่ายขนาด 4000 × 3000 มีสิบสองล้านพิกเซล บิตแมปที่ถอดรหัสแล้วจึงมีขนาดราว 48 MB ในขณะที่ไฟล์ JPEG ต้นทางอาจมีแค่ 4 MB ไฟล์โตขึ้นสิบสองเท่าก่อนงานจะเริ่มเสียด้วยซ้ำ

ขนาดของภาพหลังถอดรหัส ที่สี่ไบต์ต่อพิกเซล
ขนาดภาพจำนวนพิกเซลบิตแมปหลังถอดรหัส
1920 × 10802.1 ล้านราว 8 MB
4000 × 300012 ล้านราว 48 MB
6000 × 400024 ล้านราว 96 MB
10000 × 10000100 ล้านราว 400 MB

และสำเนาเดียวไม่เคยพอ

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

การแปลง PDF เป็นแรสเตอร์ก็เป็นแบบเดียวกันในระดับหน้าต่อหน้า หน้ากระดาษ A4 ที่เรนเดอร์ที่ 300 DPI มีขนาดราว 2480 × 3508 พิกเซล หรือราว 35 MB หลังถอดรหัส และเครื่องมือที่เรนเดอร์หลายหน้าพร้อมกันก็คูณตัวเลขนั้นขึ้นไปอีก ส่วนวิดีโอหนักกว่านั้นอีก เพราะตัวถอดรหัสต้องคงเฟรมอ้างอิงหลายเฟรมไว้ในหน่วยความจำพร้อมกัน

เพดานจริง ๆ อยู่ตรงไหน

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

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

ทำไมมือถือถึงเป็นกรณีที่เข้มงวดที่สุด

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

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

เครื่องมือที่รอบคอบทำตัวอย่างไร

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

ทำอะไรได้บ้างเมื่องานล้มเหลว

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

ขีดจำกัดของการประมาณการใด ๆ

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

เครื่องมือสำหรับเรื่องนี้

แหล่งอ้างอิง

คู่มืออื่น ๆ

คู่มือทั้งหมดของ FileSlimmer