Analýza velkých dat JSON se zdá být pomalejší, než by měla být. Stálo by za to určit příčinu a odeslat patch autorům Go.
Pokud se mezitím můžete vyhnout JSON a používat binární formát, vyhnete se nejen tomuto problému; získáte také čas, který váš kód nyní tráví analýzou ASCII desítkových reprezentací čísel do jejich binárních ekvivalentů IEEE 754 (a možná při tom může dojít k zaokrouhlování chyb.)
Pokud jsou váš odesílatel i příjemce zapsáni v Go, doporučuji použít binární formát Go:gob .
Provedením rychlého testu, vygenerováním mapy s 2000 položkami, z nichž každý je řezem s 1050 jednoduchými plovoucími objekty, mi dá 20 MB JSON, jehož analýza na mém počítači trvá 1,16 sekundy.
Pro tyto rychlé srovnávací testy jsem použil nejlepší ze tří běhů, ale ujistil jsem se, že měřím pouze skutečný čas analýzy pomocí t0 := time.Now() před voláním Unmarshal a vytištěním time.Now().Sub(t0) po něm.
Při použití GOB poskytuje stejná mapa 18 MB dat, jejichž analýza trvá 115 ms:
jednu desetinu času .
Vaše výsledky se budou lišit v závislosti na tom, kolik skutečných plováků tam máte. Pokud mají vaše plovoucí číslice mnoho platných číslic, které si zaslouží svou reprezentaci float64, pak 20 MB JSON bude obsahovat mnohem méně než moje dva miliony plovoucích. V takovém případě bude rozdíl mezi JSON a GOB stále výraznější.
BTW, to dokazuje, že problém skutečně spočívá v analyzátoru JSON, nikoli v množství dat k analýze, ani v paměťových strukturách, které je třeba vytvořit (protože oba testy analyzují ~ 20 MB dat a znovu vytvářejí stejné řezy floatů.) Nahrazení všech floatů řetězci v JSON mi poskytne čas analýzy 1,02 s, což potvrzuje, že převod z reprezentace řetězce na binární float trvá určitou dobu (ve srovnání s pouhým přesouváním bajtů), ale není hlavním viníkem.
Pokud odesílatel i analyzátor nejsou oba Go, nebo pokud chcete výkon posunout ještě dále než GOB, měli byste použít svůj vlastní přizpůsobený binární formát, buď pomocí vyrovnávací paměti protokolu, nebo ručně pomocí „kódování/binární“ a přátel.