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

Json vs. simplejson vs. ujson

jyotiska.github.io

Post reply on HN
Print view View original

1–10 of 75 posts

Re: Json vs. simplejson vs. ujson

#3

Post by foota »

I disagree with the verdict at the end of the article, it seems like json would be better if you were doing a lot of dumping? And also for the added maintenance guarantee of being an official package.

Re: Json vs. simplejson vs. ujson

#4

Post by jroseattle »

> keep in mind that ultrajson only works with well defined collections and will not work for un-serializable collections. But if you are dealing with texts, this should not be a problem.

Well-defined collections? As in, serializable? Well sure, that's requisite for the native json package as well as simplejson (as far as I can recall -- haven't used simplejson in some time.)

But does "texts" refer to strings? As in, only one data type? The source code certainly supports other types, so I wonder what this statement refers to.

Re: Json vs. simplejson vs. ujson

#7

Post by jmoiron »

When I wrote the same kind of article in Nov 2011 [1], I came to similar conculsions; ujson was blowing everyone away.

However, after swapping a fairly large and json-intensive production spider over to ujson, we noticed a large increase in memory use.

When I investigated, I discovered that simplejson reused allocated string objects, so when parsing/loading you basically got string compression for repeated string keys.

The effects were pretty large for our dataset, which was all API results from various popular websites and featured lots of lists of things with repeating keys; on a lot of large documents, the loaded mem object was sometimes 100M for ujson and 50M for simplejson. We ended up switching back because of this.

[1] http://jmoiron.net/blog/python-serialization/

Re: Json vs. simplejson vs. ujson

#9

Post by alexhill »

ktzar wrote: post #2

The usage of percentages in the article is wrong. 6 is not 150% faster than 4.

Yeah, this error is made consistently throughout the article and the author should fix it. It serves to inflate the project's performance by as much as two-thirds, and some people will see this as intentionally misleading and write your project off because of it. ultrajson looks to be way faster; don't alienate people by fudging the numbers.
Post reply on HN