-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance regression #209
Comments
Thanks for the investigation. What platform are you running on? There are some performance tests (not automatically run) in JNA's unit test suite; I believe there are some baseline numbers recorded for comparison between JNI, interface, and direct mapping (test/com/sun/jna/PerformanceTest.java). Offhand it might be some changes to libffi; I don't recall many changes to the direct mapping stuff, although I'd have to run diffs to be sure. On Mar 21, 2013, at 6:30 AM, Zlika wrote:
|
The tests were executed on Windows XP 32bit. |
Please run |
I see a drop in performance from 3.2.7 to 3.4.0 on OSX (64-bit). |
Comparison of three versions on OSX (64-bit). Checking performance of different access methods (100000 iterations, in ms).
|
Run with |
Default for preserve last error must have been "off" prior to 3.4.0. With this explicitly turned off, the numbers for 3.5.2 fall back in line with 3.2.7. There still seem to be performance issues in direct mode with |
I executed the performance test on Linux (Ubuntu 12.04 64bit) because it is more simple to compile JNA on Linux then on Windows.
|
I just made a test on one of my applications involving high speed DMA transfers: the use of -Djna.preserve_last_error=false lead to a performance increase (in terms of data transfer rate) of up to x3! |
Well, if you're calling a function and expect to be able to call errno/GetLastError, you're not expecting to have to jump through extra hoops to get operational correctness. On the other hand, if raw performance is important to you, you're usually willing to make a few tweaks to get it. Currently the overhead is in making a call back to the VM for thread-local storage; if that were implemented natively it'd avoid the extra performance hit (at the time it was easier to call back to Java than to implement per-platform thread-local storage). On Mar 26, 2013, at 5:56 AM, Zlika wrote:
|
Try out the improved_last_error branch. Should see better performance even without setting |
The direct callback regression is an artifact of the test configuration (the direct and non-direct versions of the callback overwrite one another in cache, which isn't likely to happen in real life). |
Resolved and fixed, to be released as 3.6.0. |
I'm sorry I didn't have time to test your fixes because of the birth of my first child :-) |
Hi all,
I discover a slow performance drift on the last versions of JNA.
I made 2 tests that run 2 native fonctions. The prototypes of the native fonctions are:
(Note: the 2 test functions are "real" native functions that do some real work, so the test durations do not only reflect the duration of the native calls but also the actual work of these functions).
For each test, I measure the duration of a loop of 100000 function calls with different versions of JNA (each time using Direct Mapping).
Are you aware of this performance drift?
Regards,
Thomas
The text was updated successfully, but these errors were encountered: