מגבלות זיכרון בדפדפן בעיבוד קבצים
הקובץ שלי הוא רק 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 שגדול מהמידה המרבית של הפלטפורמה פשוט נכשל, לא משנה כמה זיכרון מערכת פנוי.
אף אחת מהמגבלות האלה לא מתפרסמת כמספר יחיד שאפשר לחפש, כי הן תלויות בדפדפן, בגרסה, במכשיר ובמה שעוד רץ. זה הקושי האמיתי: כלי לא יכול לשאול כמה זיכרון מותר לו לצרוך.
למה טלפונים הם המקרה המחמיר
לטלפונים יש פחות זיכרון פיזי, אין להם swap במובן של מחשב שולחני, ומערכת ההפעלה שלהם אגרסיבית בהחזרת זיכרון מתהליכי רקע. לשונית בדפדפן היא תהליך רקע ברגע שאתם עונים להודעה. לכן דפדפנים ניידים מחזיקים תקציבים הדוקים יותר וממהרים יותר להשליך לשונית, וההשלכה נראית לכם בדרך כלל כמו דף שנטען מחדש ומאבד את העבודה שלכם, ולא כמו שגיאה.
המסקנה המעשית היא שמשימה שמסתיימת במחשב נייד עשויה להיות בלתי אפשרית בטלפון עם אותו קובץ. זה לא פגם בכלי. זה גבול חומרה, והתגובה הכנה היא לומר את זה לפני ההתחלה במקום לקרוס באמצע.
איך כלי זהיר מתנהג
- הוא מעריך את צריכת הזיכרון לפי המידות המפוענחות עוד לפני שהוא מקצה משהו, ומסרב למשימה שברור שלא תיכנס.
- הוא מעבד קובץ אחד בכל פעם במכשיר מוגבל במקום להריץ אצווה במקביל.
- הוא מעביר באפרים בין הדף לבין ה-Workers שלו במקום להעתיק אותם, כדי שקובץ גדול לא יתקיים פעמיים.
- הוא משחרר כל תוצאה מיד כשהיא נכתבת, ומבטל את כתובות ה-URL הזמניות שאחרת היו משאירות את הנתונים בחיים.
- הוא זורם עמוד אחרי עמוד או פריים אחרי פריים היכן שהפורמט מאפשר, במקום לטעון מסמך שלם לזיכרון.
- הוא מגביל את מספר הפיקסלים שהוא מוכן לקבל, וזה גם מה שמונע מקובץ קטן שמתפרש לקנבס ענק להפיל את הלשונית.
מה אפשר לעשות כשמשימה נכשלת
- סגרו לשוניות אחרות. הן מתחרות על אותו תקציב, ודפדפנים לא מחלקים אותו בהוגנות.
- עבדו על פחות קבצים בבת אחת. תור של אחד איטי יותר וסיכוייו לסיים גדולים בהרבה.
- הקטינו קודם את המידות. חיתוך הצלע הארוכה לחצי מרבע את צריכת הזיכרון, ולרוב זה גם מה שרציתם מלכתחילה.
- פצלו PDF גדול ועבדו על החלקים.
- עברו למחשב שולחני למשימות הגדולות ביותר. זה לא כישלון של עיבוד מקומי; זה השימוש הנכון בחומרה שיש לכם.
- הפעילו מחדש את הדפדפן אם לשונית פתוחה כבר ימים. לשוניות שחיות זמן רב צוברות זיכרון שרענון משחרר.
המגבלה של כל הערכה
דפדפנים חושפים רק רמז גס לגבי הזיכרון הזמין, ויש כאלה שלא חושפים כלום. לכן כל מספר שכלי מקומי מציג לכם הוא הערכה שנבנתה מהמידות של הקובץ עצמו וממודל שמרני של הצינור, ולא קריאה ממערכת ההפעלה. הוא שימושי כדי להחליט אם לנסות משימה. הוא לא הבטחה שהמשימה תסתיים, כי הגורם המכריע — מה ששאר המכשיר יעשה בשלושים השניות הבאות — אינו משהו שדף אינטרנט יכול לראות.
כלים למשימה הזו
מקורות
- W3C — WebAssembly Core Specification, memory model
- W3C — Device Memory API, and why the value is coarse
- WHATWG — HTML Standard, transferable objects