It was probably a bit too early when I last
looked at tuning ruby processing, because it preceded the processing-2.1 release (now compiled for java 7, which means I can run ruby-processing with java 8). Also since I am looking to the future I will use jruby-9000.dev for future performance tests. The esfera test is good because it is dynamic (you can actually see both compiler and garbage collector kick-in, well thats unless I'm very much mistaken). Here are past results combined with current results using jruby-complete-9000.dev (2 November 2013 snapshot). On continued running current test stabilised at ca 6 fps. What the test doesn't show is elapsed time, because there is actual pause seen when I presume compiler kicks in (and the later lesser dips in performance must be the garbage collector).
These are my java args for the test (jdk 7 unless stated)
java_args.txt
- None
- Args 1. -XX:+TieredCompilation XX:CompileCommand=dontinline,org.jruby.runtime.invokedynamic.InvokeDynamicSupport::invocationFallback
- Args 2. -XX:+TieredCompilation -XX:TieredStopAtLevel=1 XX:CompileCommand=dontinline,org.jruby.runtime.invokedynamic.InvokeDynamicSupport::invocationFallback
- Args Java 8 -Xms2048M -Xmx2048M -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=20 -XX:G1MaxNewSizePercent=80.
F.P.S esfera
| No Args |
Args 1 |
Args 2 |
Java 8 |
| 5.4547 |
5.17617 |
4.70084 |
5.27 |
| 4.26695 |
3.71662 |
2.90269 |
4.24 |
| 3.85179 |
3.22197 |
2.30053 |
3.889 |
| 3.769622 |
3.105720 |
2.077115 |
3.70 |
| 3.769622 |
3.122121 |
2.022429 |
4.15 |
| 3.756052 |
3.340643 |
1.940190 |
4.98 |
| 4.849481 |
3.122121 |
1.953019 |
5.03 |
| 5.173814 |
3.34064 |
|
5.09 |
PS: linux users it may also be worth doing the following, one-time exercise, to improve java startup
sudo java -Xshare:dump
No comments:
Post a Comment