Consider documenting IgnoreError annotation's target about jnr-ffi HOT 10 OPEN

jnr-posix suggests I'm correct, so I'm not sure why I'm seeing almost no performance impact. I guess some of the calls I'm making are already relatively slow, and the errno handling doesn't really matter?

https://github.com/jnr/jnr-posix/blob/a9dc5fb8c62e75a96d94d562b88765f647ff2f20/src/main/java/jnr/posix/LibC.java#L54

from jnr-ffi.

Can you provide a benchmark that shows no perf improvement or negative impact? I believe in #80 the options and annotations are being combined properly, but it's possible that some lower level is not honoring the result.

from jnr-ffi.

FWIW, I was able to see a benefit from IgnoreError only in the most trivial cases, like getpid which does practically no processing at the C level. The error saving is not particularly slow and ultimately boils down to one memory access and one thread-local variable assignment.

from jnr-ffi.

Sure thing! I'm using this from Clojure though, so I'm guessing you may want a different, Java-level benchmark :) The stuff I'm doing is definitely a lot "bigger" than getpid. The fastest thing I'm doing is secretbox crypto on a pre-allocated buffer, for which the mean execution time is 3.775396 µs. (I'm working on getting the files off my benchmark box now.)

from jnr-ffi.

Crud, I have to run the before-bench one more time. Bear with me :)

from jnr-ffi.

As long as the Clojure code isn't wiping out any gains from IgnoreError, it's fine. I'm a polyglot, I can deal with it?

I thought I might have saved the Java getpid benchmarks I wrote for my JNR talk some years ago, but I can't seem to find them.

from jnr-ffi.

Benchmark output: https://gist.github.com/lvh/cc2e0d5a8eecd6c631e11c39134faf5a

You can run the benchmarks yourself by cloning lvh/caesium and running (assuming you have leiningen):

lein with-profile +benchmarks test

There is one expected test failure (only for the benchmarks): that's a bug in Clojure's reflector. This tests a lot of stuff you might not care about, like e.g. reflection vs type hinted call performance, but that's the entire result :)

from jnr-ffi.

Oh, right; my apologies, I forgot you're the JRuby guy. I guess I just wanted to be as acommodating as possible since I'm getting free support :D

from jnr-ffi.

This output is very confusing for me to read...perhaps you can pare it down to the simplest case?

from jnr-ffi.

Sorry; this has fallen off my radar, but I've worked to present the data a bit better, and now using the IgnoreError LibraryOption. I'm calling (.option my-loader LibraryOption/IgnoreError true); I'm assuming that's how you use it (if not, that gives me a good idea about my std dev ;-))

The results are summarized in this Google Spreadsheet:

https://docs.google.com/a/lvh.cc/spreadsheets/d/1bEqlUNp4ZXRjkN2X50st7lWiV47NlQGIJUgidm2WgBs/edit?usp=sharing

from jnr-ffi.