बड़े JSON parsing को तेज़ करना
मुख्य बात: गलत क्रम में optimise करने से हर library बदलना बेकार हो जाता है। network, parse और render को अलग-अलग मापें, फिर parses घटाएँ, payload छोटा करें और stream करें।
मुख्य बात: पहले network, parse और render को अलग-अलग मापें — अधिकतर "धीमा parsing" असल में धीमा rendering निकलता है — फिर क्रम से सीढ़ी चढ़ें: कम parses, छोटे payloads, streaming, worker, और अंत में binary फ़ॉर्मैट।
लाइब्रेरी बदलने से शुरू न करें। एक timer जोड़ें और आमतौर पर पाएँगे कि render ही समस्या है।
पहला चरण: चरणों को मापें
const t0 = performance.now();
const response = await fetch(url);
const text = await response.text();
const t1 = performance.now();
const data = JSON.parse(text);
const t2 = performance.now();
render(data);
const t3 = performance.now();
| प्रमुख चरण | असली समस्या | समाधान |
|---|---|---|
| Network | Payload बहुत बड़ा | Field selection, pagination, compression |
JSON.parse |
सचमुच बड़ा input | कम parses, streaming, worker |
| Render | एक साथ हज़ारों नोड्स | Virtual list, paging, collapsing |
आधुनिक browsers लगभग 5–15ms में 1MB और 80–150ms में 10MB parse करते हैं। अगर 10MB दो सेकंड ले रहा है, तो JSON.parse आपकी bottleneck नहीं है।
दूसरा चरण: कम parse करें
सबसे सस्ता लाभ, और सबसे अधिक अनदेखा किया गया।
- एक ही payload को बार-बार parse करना बंद करें। दस components जो हर एक
JSON.parse(localStorage.getItem(...))कॉल करते हैं, वे दस parses हैं। module स्तर पर एक बार cache करें। - Deep copy के लिए
JSON.parse(JSON.stringify(x))उपयोग करना बंद करें। यह डेटा की मात्रा से दोगुने से अधिक खर्च करता है;structuredCloneनहीं करता। - Main thread पर parse करके object को worker को मत भेजें।
postMessageउसे दोबारा clone करता है। कच्चा text भेजें और worker को parse करने दें। - कम फ़ील्ड माँगें। अगर UI को तीन properties चाहिए, तो API तीन सौ न भेजे।
तीसरा चरण: payload छोटा करें
page/size से pagination, गहरे offset के बजाय cursors, list endpoints में summary फ़ील्ड। यह आमतौर पर सारे frontend optimisations को मिलाकर भी हरा देता है, क्योंकि यह एक साथ network, parse और memory घटाता है।
चौथा चरण: stream करें
जब डेटा को पूरी तरह process करना ही हो और वह सचमुच बड़ा हो:
import { parser } from 'stream-json';
import { streamArray } from 'stream-json/streamers/StreamArray';
const pipeline = fs.createReadStream('big.json').pipe(parser()).pipe(streamArray());
for await (const { value } of pipeline) {
await handleOne(value);
}
अधिक code, और random access नहीं — केवल record-दर-record processing के लिए उपयुक्त।
पाँचवाँ चरण: इसे main thread से हटाएँ
Parsing तेज़ है पर blocking है। इसे worker में डालें और text भेजें, parsed object नहीं, वरना structured cloning लागत दोगुनी कर देती है।
छठा चरण: फ़ॉर्मैट बदलें, सबसे आख़िर में
लगातार दसियों megabytes वाले आंतरिक traffic के लिए NDJSON स्वाभाविक रूप से stream होता है, और Protobuf या MessagePack छोटे व तेज़ हैं। दोनों protocol बदलाव हैं जिनमें तालमेल चाहिए।
न करें
- JSON को
evalकरना: असुरक्षित और तेज़ भी नहीं - JSON को JSON में embed करने के लिए stringify करना: आकार दोगुना हो जाता है
- लूप में लाखों छोटी strings parse करना: उन्हें batch करें
FAQ
पता कैसे चले कि parsing bottleneck है या rendering?
request, text पढ़ना, JSON.parse और render को performance.now() से अलग-अलग समय दें, और सबसे बड़े चरण को असली bottleneck मानें। आधुनिक browsers लगभग 5–15ms में 1MB और 80–150ms में 10MB parse करते हैं, इसलिए दो सेकंड लेने वाला 10MB payload शायद ही कभी JSON.parse की समस्या होता है।
लाइब्रेरी बदलने से आमतौर पर मदद क्यों नहीं मिलती?
JSON.parse पहले से native और तेज़ है; अधिकतर "धीमा parsing" बार-बार parsing या एक साथ हज़ारों नोड्स render करने से आता है। Library बदलने से 10–30% मिलता है, जबकि एक पूरा parse हटाने से अक्सर आधा बच जाता है।
क्या parsing को Web Worker में ले जाना चाहिए?
जब parsing main thread को block करे और पेज freeze हो या animations frames छोड़ें, तब इसे worker में ले जाएँ। parsed object के बजाय कच्चा text भेजें, वरना postMessage structured cloning लागत दोगुनी कर देती है।