You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to measure any possible performance improvements (or drops) during development (like before a PR merge or push) we need a reliable benchmarking suite.
This should test both native method calling performance AND library loading performance.
We should try to test as many scenarios as possible since we use a complicated set of strategies to bind native functions including:
x86asm and a64asm (used mostly for numeric functions), these end up becoming JVM native functions and behave differently performance-wise than others. This is loaded using AsmLibraryLoader
JVM bytecode which eventually will always (as far as I'm aware) end up calling to com.kenai.jffi.Invoker. This is also loaded using AsmLibraryLoader
java.lang.reflect.Proxys which is what we return and use when dealing with ReflectionLibraryLoader
All of these strategies have different method calling performance behaviors AND different loading performance (the latter being of particular importance to JRuby)
This suite should probably not be a part of the tests as we we don't want mvn test to always run them as they could be time consuming. But they are related, I would ideally prefer to have a benchmark function for every "User story" like a possible scenario or use case but that might be a bit too much.
We can probably use something like OpenJDK's JMH to help with this.
Personally, I also think this is an excellent opportunity to also improve and add to the current test suite but that's a separate topic.
We can even make the suite a part of the CI to measure changes between commits and hopefully not make us become too obsessed with minute performance changes 🤞
The text was updated successfully, but these errors were encountered:
In order to measure any possible performance improvements (or drops) during development (like before a PR merge or push) we need a reliable benchmarking suite.
This should test both native method calling performance AND library loading performance.
We should try to test as many scenarios as possible since we use a complicated set of strategies to bind native functions including:
x86asm
anda64asm
(used mostly for numeric functions), these end up becoming JVMnative
functions and behave differently performance-wise than others. This is loaded usingAsmLibraryLoader
com.kenai.jffi.Invoker
. This is also loaded usingAsmLibraryLoader
java.lang.reflect.Proxy
s which is what we return and use when dealing withReflectionLibraryLoader
All of these strategies have different method calling performance behaviors AND different loading performance (the latter being of particular importance to JRuby)
This suite should probably not be a part of the tests as we we don't want
mvn test
to always run them as they could be time consuming. But they are related, I would ideally prefer to have a benchmark function for every "User story" like a possible scenario or use case but that might be a bit too much.We can probably use something like OpenJDK's JMH to help with this.
Personally, I also think this is an excellent opportunity to also improve and add to the current test suite but that's a separate topic.
We can even make the suite a part of the CI to measure changes between commits and hopefully not make us become too obsessed with minute performance changes 🤞
The text was updated successfully, but these errors were encountered: