Use Class#getConstructors to check if the Pointer.class based constructor exists#1108
Use Class#getConstructors to check if the Pointer.class based constructor exists#1108bjorndarri wants to merge 1 commit intojava-native-access:masterfrom bjorndarri:master
Conversation
…ss#getConstructors and check if the Pointer.class based constructor exists
|
A benchmark comparing the two variants (slighty modified to be benchmarkable) can be found here: The numbers I got: My conclusion:
@neilcsmith-net you might be interested in this. |
|
@matthiasblaesing thanks for taking a look at that! 👍 Not as bad as I feared - the logic is similar to how the JDK will find the constructor, just not able to use internal data. Was initially surprised that the no argument constructor wasn't closer in performance, then realised it's having to allocate memory?! Not sure that's possible to workaround while backwards compatible though? For that reason, my opinion for what it's worth is still that this fix shouldn't be made, and the exception should be logged explicitly. But if this makes it in, and it causes a noticeable overhead, I'll rewrite any remaining uses we have of this. |
|
I rerun the benchmarks and also covered the option to only use the parameterless constructor. That variant comes at the price, that the structure constructor in that case always allocates memory for the structure and then switches to the provided pointer. |
|
Merged via 044cd6f. Thank you. |
Instead of using Class#getConstructor(Pointer.class) with try-catch.
Relevant thread in JNA forum
And if you want to dive into the reasons why using exceptions for control flow is inefficient:
The Exceptional Performance of Lil' Exception