NIFs have other problems too. If you have an expensive NIF in your hot path even dirty schedulers wont help you.
We did lots of rsa_private_decrypt (30% of our requests) and the BEAM did not behave well at all under load. That is to say it behaved a lot like other languages ![]()
Latency was fluctuating, requests were being starved and it was only using 60% server CPU even thought the scheduler usage was 100%. The reason being the schedulers being held up waiting for NIFs who could not yield.
I always thought NIF was the answer to performance problem, however after converting this part of the code to using ports instead our application all of a sudden behaved as it was supposed to, mainly because the erlang schedulers were able to do what they are supposed to.
This made me more cautious of using NIFs for anything remotely long-running (=> 1ms) and rather using ports for those tasks. (and always measure, measure and measure)






















