couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Joseph Davis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1118) Adding a NIF based JSON decoding/encoding module
Date Sun, 03 Apr 2011 20:26:05 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015205#comment-13015205
] 

Paul Joseph Davis commented on COUCHDB-1118:
--------------------------------------------

I need to go back and look at the numbers for encoding/decoding again to try and pin down
what the actual overhead/cost is for each method. I do remember there being some issues with
tiny docs, but they were extremely tiny. Anything of any actual size is probably going to
be faster in the NIF version.

As to the scheduler bits, I'm not sure that I'm really that concerned about it. AFAIK, its
operating under the same principles as term_to_binary, so if the JSON part is a problem for
us, then we should be looking into replacing term_to_binary with an Erlang version (which
we're not so I think we shouldn't care *too* much). Then again, figuring out a way to test
these sorts of things might be a bonus regardless.

> Adding a NIF based JSON decoding/encoding module
> ------------------------------------------------
>
>                 Key: COUCHDB-1118
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1118
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: Database Core
>            Reporter: Filipe Manana
>             Fix For: 1.2
>
>
> Currently, all the Erlang based JSON encoders and decoders are very slow, and decoding
and encoding JSON is something that we do basically everywhere.
> Via IRC, it recently discussed about adding a JSON NIF encoder/decoder. Damien also started
a thread at the development mailing list about adding NIFs to trunk.
> The patch/branch at [1] adds such a JSON encoder/decoder. It is based on Paul Davis'
eep0018 project [2]. Damien made some modifications [3] to it mostly to add support for big
numbers (Paul's eep0018 limits the precision to 32/64 bits) and a few optimizations. I made
a few corrections and minor enhancements on top of Damien's fork as well [4]. Finally BenoƮt
identified some missing capabilities compared to mochijson2 (on encoding, allow atoms as strings
and strings as object properties).
> Also, the version added in the patch at [1] uses mochijson2 when the C NIF is not loaded.
Autotools configuration was adapted to compile the NIF only when we're using an OTP release
>= R13B04 (R13B03 NIF API is too limited and suffered many changes compared to R13B04 and
R14) - therefore it should work on any OTP release > R13B at least.
> I successfully tested this on R13B03, R13B04 and R14B02 in an Ubuntu environment.
> I'm not sure if it builds at all on Windows - would appreciate if someone could verify
it.
> Also, I'm far from being good with the autotools, so I probably missed something important
or I'm doing something in a not very standard way.
> This NIF encoder/decoder is about one order of magnitude faster compared to mochijson2
and other Erlang-only solutions such as jsx. A read and writes test with relaximation shows
this has a very positive impact, specially on reads (the EJSON encoding is more expensive
than JSON decoding) - http://graphs.mikeal.couchone.com/#/graph/698bf36b6c64dbd19aa2bef634052381
> @Paul, since this is based on your eep0018 effort, do you think any other missing files
should be added (README, etap tests, etc)? Also, should we put somewhere a note this is based
on your project?
> [1] - https://github.com/fdmanana/couchdb/compare/json_nif
> [2] - https://github.com/davisp/eep0018
> [3] - https://github.com/Damienkatz/eep0018/commits/master
> [4] - https://github.com/fdmanana/eep0018/commits/final_damien

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message