[erlang-questions] couchdb performace 10x: using NIF for file io

[Martin Scholl]

I'd guess this is because the NIF blocks the current VM thread instead
of a dedicated I/O thread.


Just guessing,
Martin


On 10/24/2010 04:17 PM, Robert Virding wrote:
> One intersting thing in the graphs is the fluctuations occurring in the NIF'ed version. The old version is much more consistent, but slower. I wonder why it is so.
> 
> One problem with writing too much in C that there is a big risk that the code will contain more bugs. So while a system technically is "up" it will be less accessible if it has to restart sub-sections more often.
> 
> Robert
> 
> 
> ----- "Joel Reymont" <joelr1@REDACTED> wrote:
> 
>> Simply switching to NIFs for file IO seems to have improved CouchDB
>> write performance more than ten-fold.
>>
>> Compare the old graph
>>
>> http://graphs.mikeal.couchone.com/#/graph/62b286fbb7aa55a4b0c4cc913c00f5a4
>>
>> to the new graph
>>
>> http://graphs.mikeal.couchone.com/#/graph/62b286fbb7aa55a4b0c4cc913c00f4d7
>>
>> I was under the impression that the Erlang IO subsystem was highly
>> optimized but there seems to be no limit to perfection.
>>
>> NIFs are a giant black hole that will subsume Erlang code as
>> performance has to be improved. Start at the lowest level and keep
>> moving up. All that will be left of Erlang in the end is 99.99999%
>> uptime, fault tolerance and supervision... of optimized C code. It's
>> swell and I'm all for it!
>>
>> Patch is here:
>>
>> http://github.com/wagerlabs/couchdb/commit/23527eb8165f81e63d47b230f3297d3072c88d83
>>
>> ---
>> http://twitter.com/wagerlabs
>>
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
> 
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>