It's like JSON. but fast and small. • Hacker News Board

Re: It's like JSON. but fast and small.

#91

Post by GeorgeTirebiter » Sat, Dec 29, 2012, 11:07 PM UTC

pooriaazimi wrote: post #15

It looks cool, but be very careful about using it (in a browser, at least). Browsers have super-fast JSON parsers and parsing msgpack is much, much slower than parsing good old JSON. This great comment (from 201 days ago) is exactly about this issue: http://news.ycombinator.com/item?id=4091051 I quote a bit of it here: JSON size: 386kb MsgPack size: 332kb Difference: -14% Encoding with JSON.stringify 4 ms Encoding wi…

I find it fascinating that people claim some computer coding is "human readable" and some is not. Pencil marks on a piece of dead tree are often "human readable". Bits on a hard drive (or on a FLASH drive or in DRAM or ...) are not.

Bits on a some kind of modern electronic storage device require a program (software) to interpret them.

When people say something is not "human readable" they mean not human readable by their favorite text editor, etc. Nothing would prevent a different program from making the binary blob "human readable".

So I claim that, unless we use e.g. Williams-Kilburn tube memory, which stored bits on the screen of the CRT http://www.computerhistory.org/revolution/memory-storage/8/3... which were, in fact, "human readable", I believe it does us all a disservice to say that just because your program does not interpret the binary blob the way you like implies that somehow the binary blob itself is deficient!

Re: It's like JSON. but fast and small.

#92

Post by lucian303 » Sun, Dec 30, 2012, 1:22 AM UTC

... and not a standard.

Re: It's like JSON. but fast and small.

#93

Post by rorrr » Sun, Dec 30, 2012, 2:18 AM UTC

Too wrote: post #64

NelsonMinar wrote: post #61

Earlier quoted context omitted.

I did a quick test on some JSON data I use in my webapps; ~100k-1M blobs, mostly numbers. gzipped MessagePack data was just about the same size as gzipped JSON data. If you care about size on the wire over HTTP, then MessagePack may not be an improvement. It's amazing how well gzip compresses the stupid ASCII encoding of numbers in JSON.

Doesn't have to be stupid. A normal integer in binary representation ALWAYS consumes 4 bytes. With string representation you have 1000 numbers that will beat that as they only need <=3 characters. Numbers in that range are actually used very frequently.

> A normal integer in binary representation ALWAYS consumes 4 bytes

That's not true. Most languages have 1-byte integers, 2-byte integers and 4-byte integers.

Re: It's like JSON. but fast and small.

#94

Post by aufreak3 » Sun, Dec 30, 2012, 2:22 AM UTC

avar wrote: post #28

A comparison between msgpack and Sereal and other formats. Sereal is a format we released at work a few months ago: http://blog.booking.com/sereal-a-binary-data-serialization-f...

Looks like good work with some thought having gone into it, although with most such schemes the major gains are usually reaped with the first few simple optimizations.

Maybe you need a catchy marketing line like "Its like msgpack, but smaller and faster" :)

Re: It's like JSON. but fast and small.

#95

Post by saurik » Sun, Dec 30, 2012, 2:40 AM UTC

GeorgeTirebiter wrote: post #91

pooriaazimi wrote: post #15

It looks cool, but be very careful about using it (in a browser, at least). Browsers have super-fast JSON parsers and parsing msgpack is much, much slower than parsing good old JSON. This great comment (from 201 days ago) is exactly about this issue: http://news.ycombinator.com/item?id=4091051 I quote a bit of it here: JSON size: 386kb MsgPack size: 332kb Difference: -14% Encoding with JSON.stringify 4 ms Encoding wi…

I find it fascinating that people claim some computer coding is "human readable" and some is not. Pencil marks on a piece of dead tree are often "human readable". Bits on a hard drive (or on a FLASH drive or in DRAM or ...) are not. Bits on a some kind of modern electronic storage device require a program (software) to interpret them. When people say something is not "human readable" they mean not human readable by t…

I think that people who say that mean "without special interpretation tools"; like, where if you came across the format in the wild tou would immediately e able to understand it, at least a little, based on nothing more than an understanding of some simple protocols like SMTP and some training in common programming languages like JavaScript.

That said, personally, I find tagged-length binary protocols very easy to read with nothing more than a hex editor, and often feel that their simplicity of implementation (no state machine required for their parser) to put them much farther into the camp of "human usable" than most file formats people like to claim are "human readable".

Re: It's like JSON. but fast and small.

#96

Post by drudru11 » Sun, Dec 30, 2012, 4:14 AM UTC

I don't see any evidence presented that it is smaller or faster on this page.

Re: It's like JSON. but fast and small.

#97

Post by reeses » Sun, Dec 30, 2012, 6:03 AM UTC

rorrr wrote: post #93

Too wrote: post #64

Earlier quoted context omitted.

Doesn't have to be stupid. A normal integer in binary representation ALWAYS consumes 4 bytes. With string representation you have 1000 numbers that will beat that as they only need <=3 characters. Numbers in that range are actually used very frequently.

> A normal integer in binary representation ALWAYS consumes 4 bytes That's not true. Most languages have 1-byte integers, 2-byte integers and 4-byte integers.

Truly awesome languages use binary-coded decimal.

Ok, I'll show myself out.

Re: It's like JSON. but fast and small.

#98

Post by cjensen » Sun, Dec 30, 2012, 7:01 AM UTC

It used to be that those who do not learn from history are doomed to write yet-another string class.

Nowadays it seems that those who do not learn from history are doomed to write yet another serialization scheme.

Re: It's like JSON. but fast and small.

#99

Post by SimHacker » Sun, Dec 30, 2012, 7:50 AM UTC

Well at least they didn't name it a cute cargo cult acronym like YAML and then only later realize it actually wasn't a markup language, then have to come up with a backronym to cover up their mistake.

Re: It's like JSON. but fast and small.

#100

Post by klodolph » Sun, Dec 30, 2012, 8:47 AM UTC

adventured wrote: post #54

judofyr wrote: post #20

Earlier quoted context omitted.

sigh . Why do we always want to declare a winner? Anyone who has tried to store binary data in JSON knows that MessagePack does indeed have a use case. And anyone who is working with browsers knows that JSON/JS is the king there. > MessagePack is not smaller than gzip'd JSON But gzip'd MessagePack is smaller than gzip'd JSON, so? > MessagePack is not faster than JSON when a browser is involved Using it in the browser…

I think developers like to declare winners for very, very good reasons typically. Winners are often very useful. For example in settling on a standard once a good or great solution is found so a community can thrive around it, lots of open tools and open code can be built for it, developers can build upon it with a roadmap in mind, sites can publish with it knowing they can reach a maximum audience, etc etc etc etc.…

Thank you for taking the time to write that, instead of linking to that one comic that everyone links to in these threads about competing standards.

Although I'm not sure why you say "quasi" standard. XML and JSON seem like pretty robust standards to me, and they should both be around for a long time.