undefined | Better HN

0 pointsmahyarm9y ago0 comments

As someone who has to deal with mobile perf issues, JSON serialization/deserialization can take a lot more of a perf budget than you realize. A flatbuffer version would definitely be faster hands down.

With gzip sizing is about the same, but processing speed wise it is not.

0 comments

fulafel9y ago

Also if you gzip the binary version and the json version, the gzipped binary is still going to be much smaller.

Same with csv data, for download size it really pays off to preprocess and pack into arrays of binary structs before compression.

This is part of a bigger class of effects in preprocessing data before compression, it is often surprisingly effective. For example delta coding or columnar format (SoA vs AoS) can yield big improvements depending on data.

john_reel9y ago

See: precomp, lrzip, srep

BinaryIdiot9y ago

> As someone who has to deal with mobile perf issues, JSON serialization/deserialization can take a lot more of a perf budget than you realize. A flatbuffer version would definitely be faster hands down

With something that's grabbed once and cached likely forever I think the tiny bit of overhead for JSON won't make any difference. I've done this too and yes, of course a flatbuffer would be faster but the speed is just related to the initial download and caching. Beyond that you'd keep it in whatever structure is more efficient for the app to re-use.

mahyarmOP9y ago

Unless they store the cached version as a flatbuffer or similar format, you will suffer a penalty every app startup. And startup is where a lot of mobile perf is focused on. I haven't heard of SVG renderers storing SVG XML files in a more efficient format. It's like using jpeg2000 compressed images vs. PNG. And if you use a lot of them, it will add up.

BinaryIdiot9y ago

> Unless they store the cached version as a flatbuffer or similar format, you will suffer a penalty every app startup. And startup is where a lot of mobile perf is focused on.

Why would you pull in data from one format and keep it in the same format forever if it's not optimal for the device AND it doesn't need to be modified and sent back? Whenever I work on mobile apps and I have to cache data coming over as JSON or XML I store it where I can quickly re-access and NOT in its original format.

This thread seems like a conversation about how you can shoot yourself in the foot when it's very easy to avoid.

> I haven't heard of SVG renderers storing SVG XML files in a more efficient format.

Me neither. Sounds like it could be doable. Not sure how this related to our conversation though.

j / k navigate · click thread line to collapse

0 comments

fulafel9y ago

Also if you gzip the binary version and the json version, the gzipped binary is still going to be much smaller.

Same with csv data, for download size it really pays off to preprocess and pack into arrays of binary structs before compression.

john_reel9y ago

See: precomp, lrzip, srep

BinaryIdiot9y ago

mahyarmOP9y ago

BinaryIdiot9y ago

> Unless they store the cached version as a flatbuffer or similar format, you will suffer a penalty every app startup. And startup is where a lot of mobile perf is focused on.

This thread seems like a conversation about how you can shoot yourself in the foot when it's very easy to avoid.

> I haven't heard of SVG renderers storing SVG XML files in a more efficient format.

Me neither. Sounds like it could be doable. Not sure how this related to our conversation though.

j / k navigate · click thread line to collapse