When to NIF?

[Tim McNamara]

I guess this is more of an Erlang thing, than a Chicago Boss thing, but I expect that the audience here would have more to say about the domain than general Erlang.

Decoding streams (in my case from JSON data) is quite CPU intensive. A NIF based decoder, jiffy, is much faster than jsx, a SAX-like parser written in Erlang. When there's potentially lots of contention for the CPU, and I want to be able to have responsive web clients at the same time, would people recommend using NIF or Erlang-based approaches?

Some more info: I'm receiving a large number of incoming streams of data sourced from background processes to a web app I'm building (404ohno.com) with Chicago Boss. Messages, which are generally event notifications and less than 1kb in size, are sent to Chicago Boss are currently encoded as JSON. I spawn an Erlang process to handle the decoding, as I want the gen_server that's receiving the messages to return as soon as possible. Under stress testing, it's fairly easy for force the CPUs to 100%. I'm worried that a NIF-based decoder would decrease the responsiveness of the website, even if the work is being done more quickly.

[Konstantin Nikiforov]

> I'm worried that a NIF-based decoder
> would decrease the responsiveness of the website, even if the work is
> being done more quickly.

If you receiving JSON messages from untrusted sources, you should note
that unhandled exception inside NIF library will fully crash erlang
vm. So, this may be a risky optimization in some cases.


В Tue, 6 Nov 2012 23:02:17 +1300
Tim McNamara <mcnama...@gmail.com> пишет:

[Max Lapshin]

Yes, but juffy is really MUCH faster than anything else =)

[Evan Miller]

It's a tradeoff. I would personally avoid NIFs that performed arbitrarily long computations unless it had a dedicated thread and I knew the code was rock-solid. Here is my favorite NIF -- Tony Rogvall's OpenCL binding -- which sets up its own thread to avoid blocking the scheduler:

https://github.com/tonyrog/cl/blob/master/c_src/cl_nif.c

--
 
 

--
Evan Miller
http://www.evanmiller.org/

[Max Lapshin]

It is well known story: latency vs performance.

It is good to know thatn you can pay with latency for performance or vice versa.

--