फाइल प्रोसेस करताना ब्राउझरच्या मेमरीच्या मर्यादा

माझी फाइल फक्त 15 MB ची आहे. मग टॅबची मेमरी का संपली?

4 मिनिटांचं वाचन · १७ ऑगस्ट, २०२६ रोजी तपासलं

डिस्कवरची फाइल ही कॉम्प्रेस केलेली आवृत्ती असते

संपूर्ण गैरसमज एका वाक्यात असा आहे: फाइल मॅनेजरमध्ये दिसणारा आकडा हा कॉम्प्रेस केलेल्या डेटाचा आकार असतो, आणि कॉम्प्रेस्ड अवस्थेत असेपर्यंत कशावरही प्रक्रिया करता येत नाही. इमेजचा आकार बदलायचा असो, ती पुन्हा कॉम्प्रेस करायची असो, कन्व्हर्ट करायची असो किंवा तपासायची असो — आधी तिचं डीकोडिंग करून रॉ पिक्सेल तयार करावे लागतात, आणि रॉ पिक्सेल प्रचंड मोठे असतात.

गणित सोपं आहे. मेमरीत एक पिक्सेल साधारणपणे चार बाइट्सचा असतो — लाल, हिरवा, निळा आणि अल्फा. 4000 × 3000 चा फोटो म्हणजे 12 दशलक्ष पिक्सेल, त्यामुळे डीकोड केलेला बिटमॅप सुमारे 48 MB होतो. ज्या JPEG मधून तो आला, ती कदाचित 4 MB ची असेल. कोणतंही काम सुरू व्हायच्या आधीच फाइल बारापट मोठी झाली.

आणि एक प्रत कधीच पुरत नाही

प्रत्यक्षातली पाइपलाइन एकाच वेळी अनेक प्रती सांभाळते: कॉम्प्रेस केलेले इनपुट बाइट्स, डीकोड केलेला मूळ बिटमॅप, नव्या परिमाणांतला आउटपुट बिटमॅप, एन्कोडरचे अंतर्गत बफर, आणि कॉम्प्रेस केलेला निकाल. जे टूल तुम्हाला प्रिव्ह्यूही दाखवतं, ते आणखी एक प्रत ठेवतं. वरच्या 4000 × 3000 फोटोसाठी दोनशे ते तीनशे मेगाबाइट्सचा उच्चांकी वापर अगदी नेहमीचा आहे — आणि ती फाइल दिसायला 4 MB ची होती.

PDF रास्टरायझेशनही पानागणिक तसंच वागतं: 300 DPI वर रेंडर केलेलं A4 पान साधारण 2480 × 3508 पिक्सेलचं असतं, म्हणजे डीकोड केल्यावर सुमारे 35 MB, आणि एकाच वेळी अनेक पानं रेंडर करणारं टूल हा आकडा कैक पटींनी वाढवतं. व्हिडिओ त्याहून वाईट, कारण डीकोडरला एकाच वेळी अनेक रेफरन्स फ्रेम मेमरीत ठेवाव्या लागतात.

खऱ्या कमाल मर्यादा नेमक्या कुठे आहेत

• टॅबचं मेमरी बजेट ब्राउझर ठरवतो, साइट नाही, आणि ते मशीनमध्ये बसवलेल्या मेमरीपेक्षा कमी असतं. इतर टॅब व्यग्र असतील तेव्हा ते आणखी आकुंचन पावतं.
• नेहमीच्या 32-bit मेमरी मॉडेलसाठी बनवलेले WebAssembly मॉड्यूल जास्तीत जास्त चार गिबिबाइट्स ॲड्रेस करू शकतात, आणि ब्राउझर प्रत्येक इन्स्टन्सला बऱ्याचदा त्याहून कितीतरी कमी परवानगी देतात.
• प्रत्येक बफरची स्वतःची कमाल लांबी असते, आणि ती पेजला वापरता येणाऱ्या एकूण मेमरीपेक्षा खूपच कमी असते.
• मोबाइल ऑपरेटिंग सिस्टिम फार मोठा होणारा टॅब बंद करून टाकतात — आधी कोणतीही सूचना न देता, आणि पेजला पकडता येईल अशी कोणतीही एरर न देता.
• ग्राफिक्स मेमरी हा वेगळा, त्याहून लहान साठा असतो. प्लॅटफॉर्मच्या कमाल परिमाणापेक्षा मोठा Canvas सरळ अपयशी ठरतो, सिस्टिम मेमरी कितीही मोकळी असली तरी.

यांपैकी एकही मर्यादा तुम्हाला बघता येईल असा एकच आकडा म्हणून कुठे जाहीर केलेली नाही, कारण त्या ब्राउझर, त्याची आवृत्ती, डिव्हाइस आणि आणखी काय चालू आहे यावर अवलंबून असतात. खरी अडचण हीच आहे: आपल्याला किती मेमरी वापरता येईल हे टूलला विचारताच येत नाही.

फोन हीच सर्वात कडक केस का ठरते

फोनमध्ये फिजिकल मेमरी कमी असते, डेस्कटॉपसारखी स्वॅपची सोय नसते, आणि बॅकग्राउंड प्रोसेसकडून मेमरी परत ओढून घेण्याबाबत ऑपरेटिंग सिस्टिम आक्रमक असते. तुम्ही एका मेसेजला उत्तर देताच ब्राउझर टॅब बॅकग्राउंड प्रोसेस बनतो. त्यामुळे मोबाइल ब्राउझर अधिक घट्ट बजेट ठेवतात आणि टॅब लवकर टाकून देतात, आणि हे टाकून देणं तुम्हाला एररसारखं न दिसता पेज रीलोड होऊन तुमचं काम गेल्यासारखं दिसतं.

याचा व्यावहारिक परिणाम असा की, जे काम लॅपटॉपवर पूर्ण होतं तेच त्याच फाइलसह फोनवर अशक्य असू शकतं. हा टूलमधला दोष नाही. ही हार्डवेअरची सीमा आहे, आणि अर्ध्यात कोसळण्यापेक्षा सुरुवातीलाच तसं सांगणं हा प्रामाणिक प्रतिसाद आहे.

काळजीपूर्वक बनवलेलं टूल कसं वागतं

• काहीही ॲलोकेट करण्याआधी ते डीकोड केलेल्या परिमाणांवरून लागणाऱ्या मेमरीचा अंदाज बांधतं, आणि जे काम स्पष्टपणे बसणार नाही ते नाकारतं.
• मर्यादित क्षमतेच्या डिव्हाइसवर ते बॅच समांतर चालवण्याऐवजी एका वेळी एकच फाइल प्रोसेस करतं.
• पेज आणि तिच्या वर्करमध्ये बफरची कॉपी करण्याऐवजी ते बफर ट्रान्सफर करतं, म्हणजे मोठी फाइल मेमरीत दोनदा राहत नाही.
• प्रत्येक निकाल लिहून होताच ते तो मोकळा करतं, आणि अन्यथा डेटा जिवंत ठेवणाऱ्या तात्पुरत्या URL रद्द करतं.
• फॉरमॅट परवानगी देत असेल तिथे ते संपूर्ण दस्तऐवज मेमरीत न घेता पानागणिक किंवा फ्रेमगणिक स्ट्रीम करतं.
• ते स्वीकारणार असलेल्या पिक्सेलच्या संख्येवर मर्यादा घालतं — आणि तेच प्रचंड मोठ्या Canvas मध्ये फुगणाऱ्या लहानशा फाइलला टॅब पाडण्यापासून रोखतं.

काम फसलं तर तुम्ही काय करू शकता

• इतर टॅब बंद करा. ते त्याच बजेटसाठी स्पर्धा करत असतात, आणि ब्राउझर ते न्याय्यपणे वाटत नाहीत.
• एका वेळी कमी फाइल प्रोसेस करा. एकाच फाइलची रांग हळू चालते, पण पूर्ण होण्याची शक्यता कितीतरी जास्त असते.
• आधी परिमाणं कमी करा. सर्वात लांब बाजू निम्मी केली की लागणारी मेमरी एक चतुर्थांश होते, आणि बऱ्याचदा तुम्हाला हवं होतं तेच ते असतं.
• मोठी PDF तुकड्यांत विभागा आणि तुकडे वेगवेगळे प्रोसेस करा.
• सर्वात मोठ्या कामांसाठी डेस्कटॉप मशीनवर जा. हे लोकल प्रोसेसिंगचं अपयश नाही; तुमच्याकडे असलेल्या हार्डवेअरचा हाच योग्य वापर आहे.
• एखादा टॅब कित्येक दिवस उघडा असेल तर ब्राउझर पुन्हा सुरू करा. दीर्घकाळ उघड्या टॅबमध्ये मेमरी साचत जाते, आणि रीलोड केल्यावर ती मोकळी होते.

कोणत्याही अंदाजाची मर्यादा

उपलब्ध मेमरीबद्दल ब्राउझर फक्त ढोबळ इशारा देतात, आणि काही तर तेवढंही देत नाहीत. त्यामुळे लोकल टूल तुम्हाला दाखवतं तो कोणताही आकडा हा फाइलच्याच परिमाणांवरून आणि पाइपलाइनच्या सावध मॉडेलवरून बांधलेला अंदाज असतो, ऑपरेटिंग सिस्टिमकडून घेतलेलं वाचन नव्हे. एखादं काम करून बघावं की नाही हे ठरवायला तो उपयोगी आहे. ते काम पूर्ण होईलच असं वचन तो नाही, कारण निर्णायक घटक — पुढच्या तीस सेकंदांत बाकीचं डिव्हाइस काय करत असेल — हा वेब पेजला दिसतच नाही.

यासाठीची टूल्स

• प्रतिमा संकुचित करा
• PDF ते JPG
• व्हिडिओ संकुचित करा

स्रोत

• W3C — WebAssembly Core Specification, memory model
• W3C — Device Memory API, and why the value is coarse
• WHATWG — HTML Standard, transferable objects

आणखी मार्गदर्शक

FileSlimmer ची सर्व मार्गदर्शकं