ফাইল প্রসেস করার সময় ব্রাউজারের মেমোরির সীমা
আমার ফাইলটা তো মাত্র 15 MB। ট্যাবের মেমোরি ফুরাল কেন?
ডিস্কে থাকা ফাইলটাই কম্প্রেস করা সংস্করণ
পুরো ভুল বোঝাবুঝিটা এক বাক্যে: ফাইল ম্যানেজারে আপনি যে সংখ্যাটা দেখেন সেটা কম্প্রেস করা ডেটার সাইজ, আর কম্প্রেস করা অবস্থায় কিছুই প্রসেস করা যায় না। কোনো ইমেজ রিসাইজ করতে, আবার কম্প্রেস করতে, কনভার্ট করতে বা বিশ্লেষণ করতে হলে আগে সেটাকে কাঁচা পিক্সেলে ডিকোড করতে হয়, আর কাঁচা পিক্সেল বিশাল।
হিসাবটা সরল। মেমোরিতে একটা পিক্সেল সাধারণত চার বাইট — লাল, সবুজ, নীল আর আলফা। 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-বিট মেমোরি মডেলের জন্য বানানো WebAssembly মডিউল সর্বোচ্চ চার গিবিবাইট পর্যন্ত অ্যাড্রেস করতে পারে, আর ব্রাউজার প্রায়ই প্রতিটি ইনস্ট্যান্সে তার চেয়ে অনেক কম অনুমতি দেয়।
- প্রতিটি বাফারের নিজস্ব সর্বোচ্চ দৈর্ঘ্য আছে, যা একটা পেজ মোট যত মেমোরি ব্যবহার করতে পারে তার চেয়ে অনেক নিচে।
- মোবাইল অপারেটিং সিস্টেম বেশি বড় হয়ে যাওয়া ট্যাব বন্ধ করে দেয় — কোনো সতর্কবার্তা ছাড়াই, আর পেজ ধরতে পারে এমন কোনো এররও ছাড়াই।
- গ্রাফিক্স মেমোরি আলাদা, ছোট একটা ভাণ্ডার। প্ল্যাটফর্মের সর্বোচ্চ ডাইমেনশনের চেয়ে বড় ক্যানভাস কেবল ব্যর্থ হয়, সিস্টেম মেমোরি যতই খালি থাকুক।
এর কোনোটাই এমন একটা সংখ্যা হিসেবে প্রকাশিত নয় যা দেখে নেওয়া যায়, কারণ এগুলো নির্ভর করে ব্রাউজার, সংস্করণ, ডিভাইস আর আর কী কী চলছে তার উপর। আসল অসুবিধা এখানেই: কোনো টুল জিজ্ঞেস করতে পারে না যে সে কতটা মেমোরি ব্যবহার করতে পারবে।
ফোন কেন সবচেয়ে কড়া ক্ষেত্র
ফোনে ফিজিক্যাল মেমোরি কম, ডেস্কটপের অর্থে কোনো সোয়াপ নেই, আর অপারেটিং সিস্টেম ব্যাকগ্রাউন্ড প্রসেস থেকে মেমোরি ফেরত নিতে বেশ আক্রমণাত্মক। আপনি কোনো বার্তার জবাব দিতে গেলেই ব্রাউজার ট্যাবটা ব্যাকগ্রাউন্ড প্রসেস হয়ে যায়। তাই মোবাইল ব্রাউজার আরও কড়া বাজেট ধরে রাখে আর দ্রুত ট্যাব ফেলে দেয়, আর সেই ফেলে দেওয়াটা আপনার চোখে এররের মতো নয়, বরং পেজ রিলোড হয়ে আপনার কাজ হারিয়ে যাওয়ার মতো দেখায়।
এর বাস্তব ফল হলো, ল্যাপটপে যে কাজ শেষ হয়, একই ফাইল নিয়ে সেটাই ফোনে অসম্ভব হতে পারে। এটা টুলের ত্রুটি নয়। এটা হার্ডওয়্যারের সীমানা, আর সৎ আচরণ হলো মাঝপথে ক্র্যাশ করার বদলে শুরুর আগেই সেটা বলে দেওয়া।
সতর্ক একটা টুল কেমন আচরণ করে
- কিছু বরাদ্দ করার আগেই ডিকোড করা ডাইমেনশন থেকে ওয়ার্কিং সেটের হিসাব কষে নেয়, আর স্পষ্টতই আঁটবে না এমন কাজ করতে অস্বীকার করে।
- সীমিত সামর্থ্যের ডিভাইসে সমান্তরালে ব্যাচ না চালিয়ে একবারে একটা ফাইল প্রসেস করে।
- পেজ আর তার ওয়ার্কারদের মধ্যে বাফার কপি না করে হস্তান্তর করে, যাতে বড় ফাইল দুবার না থাকে।
- প্রতিটি ফলাফল লেখা হওয়ার সঙ্গে সঙ্গে ছেড়ে দেয়, আর যেসব অস্থায়ী URL না হলে ডেটাটা বাঁচিয়ে রাখত সেগুলো বাতিল করে।
- ফরম্যাট অনুমতি দিলে গোটা ডকুমেন্ট মেমোরিতে না তুলে পাতায় পাতায় বা ফ্রেমে ফ্রেমে স্ট্রিম করে।
- সে যত পিক্সেল নেবে তার একটা সীমা বেঁধে দেয়, আর এটাই ছোট একটা ফাইলকে বিশাল ক্যানভাসে ফুলে উঠে ট্যাবটাকে বসিয়ে দেওয়া থেকে ঠেকায়।
কাজ ব্যর্থ হলে আপনি কী করতে পারেন
- অন্য ট্যাবগুলো বন্ধ করুন। সেগুলো একই বাজেটের জন্য প্রতিযোগিতা করছে, আর ব্রাউজার সেটা ন্যায্যভাবে ভাগ করে না।
- একসঙ্গে কম ফাইল প্রসেস করুন। একটা ফাইলের সারি ধীর, কিন্তু শেষ হওয়ার সম্ভাবনা অনেক বেশি।
- আগে ডাইমেনশন কমান। দীর্ঘতম বাহু অর্ধেক করলে ওয়ার্কিং সেট এক-চতুর্থাংশ হয়ে যায়, আর প্রায়ই এটাই আপনি চাইছিলেন।
- বড় PDF ভাগ করে অংশগুলো প্রসেস করুন।
- সবচেয়ে বড় কাজগুলোর জন্য ডেস্কটপ মেশিনে যান। এটা লোকাল প্রসেসিংয়ের ব্যর্থতা নয়; এটা আপনার হাতে থাকা হার্ডওয়্যারের সঠিক ব্যবহার।
- কোনো ট্যাব কয়েক দিন ধরে খোলা থাকলে ব্রাউজারটা আবার চালু করুন। বহুদিন খোলা থাকা ট্যাবে এমন মেমোরি জমে, যা রিলোড করলে ছেড়ে যায়।
যেকোনো হিসাবের সীমা
ব্রাউজার পাওয়া যায় এমন মেমোরি নিয়ে কেবল মোটা দাগের একটা আভাস দেয়, আর কেউ কেউ কিছুই দেয় না। তাই লোকাল কোনো টুল আপনাকে যে সংখ্যাই দেখাক, সেটা ফাইলের নিজের ডাইমেনশন আর পাইপলাইনের একটা রক্ষণশীল মডেল থেকে বানানো একটা হিসাব, অপারেটিং সিস্টেম থেকে নেওয়া কোনো পাঠ নয়। কাজটা আদৌ চেষ্টা করবেন কি না তা ঠিক করতে এটা কাজে লাগে। কিন্তু কাজটা শেষ হবেই, এটা তার কোনো প্রতিশ্রুতি নয়, কারণ নির্ধারক বিষয়টা — পরের ত্রিশ সেকেন্ডে ডিভাইসের বাকি অংশ কী করছে — কোনো ওয়েব পেজের দেখার সাধ্য নেই।
এই কাজের টুল
সূত্র
- W3C — WebAssembly Core Specification, memory model
- W3C — Device Memory API, and why the value is coarse
- WHATWG — HTML Standard, transferable objects