Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Very low footprint JSON parser in portable ANSI C

github.com

Post reply on HN
Print view View original

21–30 of 58 posts

Re: Show HN: Very low footprint JSON parser in portable ANSI C

#21

Post by justincormack »

udp wrote: post #15
michael_miller wrote: post #14

Earlier quoted context omitted.

http://www.ietf.org/rfc/rfc4627 specifies that the encoding must be Unicode: "JSON text SHALL be encoded in Unicode. The default encoding is UTF-8."

I'm assuming UTF-8, so the characters I'm looking for should match up fine (\u escape sequences are also converted to UTF-8 for output).

\u is utf16 so you should be able to append two characters to get something in the extended unicode set outside ucs16. You dont seem to handle this; not sure how many parsers do.

Also not sure you handle the case where the json invalidly terminates in the middle of a \u sequence.

Just from a quick glance though, may be wrong.

Re: Show HN: Very low footprint JSON parser in portable ANSI C

#22

Post by nknight »

parenthesis wrote: post #19
udp wrote: post #9

Earlier quoted context omitted.

> why are the flag values not enums (and why is 4 missing?)? What would the advantage of using an enum be? (and I guess I used 4 and then removed it later.) > is using a lookup table for decoding hex really faster than the (minimal) logic (what if it causes cache misses)? No idea, that's just the way I did it. Feel free to try something else and profile if you're really that concerned. > do you really think that a st…

> You're not supposed to mix code and value declarations in ANSI C You can in C99.

In ordinary usage, "ANSI C" is a synonym for strict C89. C99 is not well-supported by many compilers, so code intended to be widely portable is still frequently written to strict C89.

Re: Show HN: Very low footprint JSON parser in portable ANSI C

#24

Post by shtylman »

udp wrote: post #5
avar wrote: post #4

Any reason you roll your own numeric() instead of using isdigit()? It's in C89.

Just to be sure it's inlined, really. Although I assume isdigit would be, being a compiler built-in.

Seems like a premature optimization. Don't assume, check the assembly if you care :)

Re: Show HN: Very low footprint JSON parser in portable ANSI C

#25

Post by mape »

Another alternative, https://github.com/esnme/ultrajson

"Ultra fast JSON decoder and encoder written in C with Python bindings"

From the people that built the Battlefield 3 web portal.

Medium complex object:

ujson encode : 18757.01101 calls/sec

yajl encode : 6315.14030 calls/sec

simplejson encode : 5542.03928 calls/sec

cjson encode : 4651.59072 calls/sec

---------

ujson decode : 10759.69649 calls/sec

simplejson decode : 8148.35221 calls/sec

cjson decode : 7931.04387 calls/sec

yajl decode : 5887.38201 calls/sec

Re: Show HN: Very low footprint JSON parser in portable ANSI C

#26

Post by pjscott »

udp wrote: post #9
andrewcooke wrote: post #6

why are the flag values not enums (and why is 4 missing?)? is using a lookup table for decoding hex really faster than the (minimal) logic (what if it causes cache misses)? do you really think that a state machine with bit flags is the best way to express the logic here? is string_add meant to increment string_length on subsequent passes? what is "json_value * cur_value" supposed to do at the top of json_value_free (…

> why are the flag values not enums (and why is 4 missing?)? What would the advantage of using an enum be? (and I guess I used 4 and then removed it later.) > is using a lookup table for decoding hex really faster than the (minimal) logic (what if it causes cache misses)? No idea, that's just the way I did it. Feel free to try something else and profile if you're really that concerned. > do you really think that a st…

I've converted the lookup table to a few lines of logic. I think it's more readable, and I would definitely bet on it being faster, though since I haven't profiled I don't know how much difference it would make.

https://github.com/PeterScott/json-parser/commit/db9c326f747...

Re: Show HN: Very low footprint JSON parser in portable ANSI C

#28

Post by udp »

pjscott wrote: post #26
udp wrote: post #9

Earlier quoted context omitted.

> why are the flag values not enums (and why is 4 missing?)? What would the advantage of using an enum be? (and I guess I used 4 and then removed it later.) > is using a lookup table for decoding hex really faster than the (minimal) logic (what if it causes cache misses)? No idea, that's just the way I did it. Feel free to try something else and profile if you're really that concerned. > do you really think that a st…

I've converted the lookup table to a few lines of logic. I think it's more readable, and I would definitely bet on it being faster, though since I haven't profiled I don't know how much difference it would make. https://github.com/PeterScott/json-parser/commit/db9c326f747...

Yeah, I'll go with that - cheers.

Re: Show HN: Very low footprint JSON parser in portable ANSI C

#29

Post by haberman »

aliguori wrote: post #11

There definitely is a lack of good JSON parsers for C. We wrote our own in QEMU. The relevant code is: http://git.qemu.org/?p=qemu.git;a=blob;f=json-lexer.c;h=3cd3... http://git.qemu.org/?p=qemu.git;a=blob;f=json-parser.c;h=849... Among other things, this supports streaming, is fairly fast, and has gotten a fair bit of scrutiny against malicious input. The lexer is a hand written state machine which seems like someth…

What's wrong with YAJL?
Post reply on HN