ఫైల్‌లను ప్రాసెస్ చేసేటప్పుడు బ్రౌజర్ మెమరీ పరిమితులు
నా ఫైల్ 15 MB మాత్రమే. మరి ట్యాబ్‌కు మెమరీ ఎందుకు సరిపోలేదు?
డిస్క్‌లో ఉన్న ఫైల్ అనేది కంప్రెస్ అయిన రూపం
పొరపాటు మొత్తం ఒక్క వాక్యంలో ఇదే: ఫైల్ మేనేజర్‌లో మీకు కనిపించే సంఖ్య కంప్రెస్ అయిన డేటా సైజు, ఆ డేటా కంప్రెస్ అయి ఉన్నంత వరకు దానిపై ఏ పనీ చేయలేం. ఒక ఇమేజ్‌ను రీసైజ్ చేయాలన్నా, మళ్ళీ కంప్రెస్ చేయాలన్నా, కన్వర్ట్ చేయాలన్నా, విశ్లేషించాలన్నా — ముందు దాన్ని ముడి పిక్సెల్స్‌గా డీకోడ్ చేయాల్సిందే, ఆ ముడి పిక్సెల్స్ చాలా భారీగా ఉంటాయి.
లెక్క చాలా సులభం. మెమరీలో ఒక పిక్సెల్ సాధారణంగా నాలుగు బైట్‌లు — ఎరుపు, ఆకుపచ్చ, నీలం, ఆల్ఫా. 4000 × 3000 ఫొటో అంటే 1.2 కోట్ల పిక్సెల్స్, అంటే డీకోడ్ అయిన బిట్‌మ్యాప్ దాదాపు 48 MB. అది వచ్చిన JPEG బహుశా 4 MB ఉండి ఉంటుంది. పని మొదలు కాకముందే ఫైల్ 12 రెట్లు పెరిగింది.
| కొలతలు | పిక్సెల్స్ | డీకోడ్ అయిన బిట్‌మ్యాప్ |
|---|---|---|
| 1920 × 1080 | 21 లక్షలు | సుమారు 8 MB |
| 4000 × 3000 | 1.2 కోట్లు | సుమారు 48 MB |
| 6000 × 4000 | 2.4 కోట్లు | సుమారు 96 MB |
| 10000 × 10000 | 10 కోట్లు | సుమారు 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