فائلیں پروسیس کرتے وقت براؤزر کی میموری کی حدیں

میری فائل تو صرف 15 MB کی ہے۔ پھر ٹیب کی میموری کیوں ختم ہو گئی؟

6 منٹ کا مطالعہ · 17 اگست، 2026 کو نظرثانی شدہ

ڈسک پر پڑی فائل کمپریس شدہ صورت ہوتی ہے

ساری غلط فہمی ایک جملے میں یہ ہے: فائل مینیجر میں آپ کو جو عدد نظر آتا ہے وہ کمپریس شدہ ڈیٹا کا حجم ہے، اور کمپریس حالت میں کسی چیز پر کام نہیں ہو سکتا۔ کسی تصویر کا سائز بدلنے، اسے دوبارہ کمپریس کرنے، تبدیل کرنے یا اس کا تجزیہ کرنے کے لیے پہلے اسے خام پکسلز میں ڈی کوڈ کرنا پڑتا ہے، اور خام پکسل بہت بھاری ہوتے ہیں۔

حساب سیدھا ہے۔ میموری میں ایک پکسل عام طور پر چار بائٹس کا ہوتا ہے — سرخ، سبز، نیلا اور الفا۔ 4000 × 3000 کی تصویر میں 12 ملین پکسل ہوتے ہیں، یعنی ڈی کوڈ شدہ بٹ میپ تقریباً 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 کی ریسٹرائزیشن بھی صفحہ بہ صفحہ اسی طرح چلتی ہے: 300 DPI پر رینڈر کیا گیا A4 صفحہ تقریباً 2480 × 3508 پکسل بنتا ہے، ڈی کوڈ ہونے پر تقریباً 35 MB، اور جو ٹول ایک ساتھ کئی صفحے رینڈر کرے وہ اسے کئی گنا کر دیتا ہے۔ ویڈیو اس سے بھی بھاری ہے، کیونکہ ڈی کوڈر کو ایک ہی وقت میں کئی ریفرنس فریم میموری میں رکھنے پڑتے ہیں۔

اصل حدیں کہاں ہیں

ٹیب کا میموری بجٹ براؤزر طے کرتا ہے، سائٹ نہیں، اور یہ مشین میں لگی ہوئی کل میموری سے کم ہوتا ہے۔ جب دوسرے ٹیبز مصروف ہوں تو یہ مزید سکڑ جاتا ہے۔
عام 32-bit میموری ماڈل کے لیے بنائے گئے WebAssembly ماڈیول زیادہ سے زیادہ چار گیبی بائٹ تک ہی رسائی رکھ سکتے ہیں، اور براؤزر اکثر فی انسٹینس اس سے کہیں کم کی اجازت دیتے ہیں۔
ہر بفر کی اپنی زیادہ سے زیادہ لمبائی ہوتی ہے، جو اُس کل میموری سے کافی نیچے رہتی ہے جو ایک صفحہ استعمال کر سکتا ہے۔
موبائل آپریٹنگ سسٹم ایسے ٹیب کو ختم کر دیتے ہیں جو بہت بڑا ہو جائے — بغیر کسی وارننگ کے اور بغیر کوئی ایسی ایرر دیے جسے صفحہ پکڑ سکے۔
گرافکس میموری ایک الگ، چھوٹا ذخیرہ ہے۔ پلیٹ فارم کی زیادہ سے زیادہ حد سے بڑا کینوس بس ناکام ہو جاتا ہے، چاہے سسٹم کی کتنی ہی میموری خالی کیوں نہ ہو۔

ان میں سے کوئی حد ایسے ایک عدد کی صورت شائع نہیں ہوتی جسے آپ دیکھ سکیں، کیونکہ یہ براؤزر، اس کے ورژن، ڈیوائس اور اس بات پر منحصر ہیں کہ اور کیا کچھ چل رہا ہے۔ اصل مشکل یہی ہے: کوئی ٹول پوچھ ہی نہیں سکتا کہ اسے کتنی میموری استعمال کرنے کی اجازت ہے۔

فون سب سے سخت صورت کیوں ہیں

فون میں جسمانی میموری کم ہوتی ہے، ڈیسک ٹاپ والے معنوں میں سواپ نہیں ہوتا، اور آپریٹنگ سسٹم بیک گراؤنڈ پروسیسز سے میموری واپس لینے میں سخت گیر ہوتا ہے۔ جس لمحے آپ کسی پیغام کا جواب دیتے ہیں، براؤزر کا ٹیب بیک گراؤنڈ پروسیس بن جاتا ہے۔ اسی لیے موبائل براؤزر زیادہ تنگ بجٹ رکھتے ہیں اور ٹیب کو جلد چھوڑ دیتے ہیں، اور یہ چھوڑنا آپ کو عموماً ایرر کے بجائے یوں دکھائی دیتا ہے کہ صفحہ دوبارہ لوڈ ہو گیا اور آپ کا کام ضائع ہو گیا۔

عملی نتیجہ یہ ہے کہ جو کام لیپ ٹاپ پر مکمل ہو جاتا ہے، وہی فائل فون پر ناممکن ہو سکتی ہے۔ یہ ٹول کی خرابی نہیں۔ یہ ہارڈویئر کی حد ہے، اور ایمانداری کا تقاضا یہ ہے کہ آدھے راستے میں کریش ہونے کے بجائے شروع سے پہلے ہی بتا دیا جائے۔

محتاط ٹول کیسا برتاؤ کرتا ہے

کچھ بھی مختص کرنے سے پہلے یہ ڈی کوڈ شدہ ابعاد سے ورکنگ سیٹ کا اندازہ لگاتا ہے، اور ایسا کام قبول نہیں کرتا جو صاف طور پر سما ہی نہیں سکتا۔
محدود سکت والی ڈیوائس پر یہ پورا بیچ ایک ساتھ چلانے کے بجائے ایک وقت میں ایک فائل پروسیس کرتا ہے۔
یہ صفحے اور اس کے ورکرز کے درمیان بفرز نقل کرنے کے بجائے منتقل کرتا ہے، تاکہ بڑی فائل دو بار موجود نہ ہو۔
ہر نتیجہ لکھے جاتے ہی چھوڑ دیتا ہے، اور وہ عارضی URLs منسوخ کر دیتا ہے جو ورنہ ڈیٹا کو زندہ رکھتے۔
جہاں فارمیٹ اجازت دے، یہ پوری دستاویز میموری میں لادنے کے بجائے صفحہ بہ صفحہ یا فریم بہ فریم اسٹریم کرتا ہے۔
یہ پکسلوں کی تعداد پر حد لگاتا ہے، اور یہی وہ چیز ہے جو کسی چھوٹی فائل کو، جو پھیل کر بہت بڑا کینوس بن جاتی ہے، ٹیب گرانے سے روکتی ہے۔

کام ناکام ہو جائے تو آپ کیا کر سکتے ہیں

دوسرے ٹیبز بند کریں۔ وہ اسی بجٹ کے لیے مقابلہ کر رہے ہیں، اور براؤزر اسے انصاف سے تقسیم نہیں کرتے۔
ایک وقت میں کم فائلیں پروسیس کریں۔ ایک فائل کی قطار سست ہے مگر مکمل ہونے کا امکان کہیں زیادہ رکھتی ہے۔
پہلے ابعاد کم کریں۔ سب سے لمبے کنارے کو آدھا کرنے سے ورکنگ سیٹ چوتھائی رہ جاتا ہے، اور اکثر آپ کو یہی درکار ہوتا ہے۔
بڑی PDF کو تقسیم کریں اور حصے الگ الگ پروسیس کریں۔
سب سے بڑے کاموں کے لیے ڈیسک ٹاپ مشین پر جائیں۔ یہ لوکل پروسیسنگ کی ناکامی نہیں؛ یہ آپ کے موجود ہارڈویئر کا درست استعمال ہے۔
اگر کوئی ٹیب کئی دن سے کھلا ہے تو براؤزر دوبارہ شروع کریں۔ دیر تک کھلے ٹیبز میں میموری جمع ہوتی رہتی ہے، جو ری لوڈ سے آزاد ہو جاتی ہے۔

ہر اندازے کی اپنی حد

براؤزر دستیاب میموری کے بارے میں صرف ایک موٹا سا اشارہ دیتے ہیں، اور کچھ تو کچھ بھی نہیں دیتے۔ اس لیے کوئی لوکل ٹول آپ کو جو عدد بھی دکھائے، وہ فائل کے اپنے ابعاد اور پائپ لائن کے ایک محتاط ماڈل سے بنایا گیا اندازہ ہوتا ہے، آپریٹنگ سسٹم سے لی گئی پیمائش نہیں۔ یہ فیصلہ کرنے کے لیے کارآمد ہے کہ کام شروع کیا جائے یا نہیں۔ یہ اس بات کا وعدہ نہیں کہ کام مکمل ہو جائے گا، کیونکہ فیصلہ کن عنصر — یعنی اگلے تیس سیکنڈ میں باقی ڈیوائس کیا کر رہی ہوگی — کوئی ویب صفحہ دیکھ ہی نہیں سکتا۔

اس کام کے ٹولز

مآخذ

مزید گائیڈز

FileSlimmer کے تمام گائیڈز