Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Message-ID: <29618337.226341290388153232.JavaMail.jira@thor>
Date: Sun, 21 Nov 2010 20:09:13 -0500 (EST)
From: "Adam Kocoloski (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Subject: [jira] Commented: (COUCHDB-798) Compile mochijson2 down to native
 code
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Adam Kocoloski commented on COUCHDB-798:
----------------------------------------

Indeed, and seemingly contradicts the results I posted earlier in this ticket.  I didn't observe any change with small docs, but with large docs the average client response time dropped dramatically in a 90 second test with 200 writer clients.

> Compile mochijson2 down to native code
> --------------------------------------
>
>                 Key: COUCHDB-798
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-798
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: Database Core
>            Reporter: Adam Kocoloski
>             Fix For: 1.2
>
>
> Adding a -compile(native) flag to mochijson2.erl results in a marked performance improvement for large documents.  I did the following test
> node compare_write.js -u http://127.0.0.1:5984 -v http://127.0.0.1:5985 -1 trunk -2 mochijson2-native -d large -r 2 -t 90 -c 200
> and got the results at [1].  The graph shows that the average client response time dropped by about 35% with the native encoder.  Qualitatively, I also noticed that the native encoder used substantially fewer CPU cycles.  On my dual core Macbook, idle CPU went from ~10% on trunk to ~25% with the +native version while the test was running.
> Running the same test with small documents showed essentially no difference between the two comparatives, which is not surprising.
> A potential downside of +native is instability in the VM.  I've encountered issues on AMD machines with R13B04 when using +native for all modules, and the core dump pointed to an issue in HiPE.  On the other hand, I think that mochijson2 should work very well as native code, since it doesn't do any message passing or I/O.  I'm +1 on simply adding the compile option to the codebase in trunk to see how it behaves.
> [1]: http://mikeal.couchone.com/graphs/_design/app/_show/compareWriteTest/e69057a29bd6e4ac4ae0115fac00ae50

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.