Time to embrace jdk1.8.0 for ruby-processing (don't try this with vanilla processing).

There are performance improvements to be had if you switch to using jdk8 with ruby-processing, if you are a jEdit user it is dead simple just modify the bsh macro (gist below) to suit your system. While you are at it you can experiment with ruby-2.0 syntax (current default is ruby-1.9.3 with jruby). Check it with esefera.rb (starts of at moderate speed, even slows down briefly but the picks up again as the optimizations kick in). See below or gist (embedded gist looked crap).

// rp5.bsh
//setenv("JAVA_HOME", "/opt/jdk1.7.0_51");
setenv("JAVA_HOME", "/opt/jdk1.8.0");
setenv("GEM_HOME", "/home/tux/.gem/ruby/2.1.0");
setenv("GEM_PATH", "/home/tux/.gem/ruby/2.1.0");
new console.commando.CommandoDialog(view,"commando.rp5");

<!-- rp5.xml monkstone, 2013-August-16 for ruby-processing > 2.0.12 -->
<COMMANDO>
<UI>
<CAPTION LABEL="Run">
<FILE_ENTRY LABEL="ruby file" VARNAME="file" EVAL="buffer.getName()"/>
</CAPTION>
<CAPTION LABEL="Path to rp5">
<ENTRY LABEL="path" VARNAME="rp5path" DEFAULT=""/>
</CAPTION>
<CAPTION LABEL="Choose Run/Watch/Create/App">
<CHOICE LABEL="Select" VARNAME="type" DEFAULT="run" >
<OPTION  LABEL="run" VALUE="run"/>
<OPTION LABEL="watch" VALUE="watch"/>
<OPTION LABEL="create" VALUE="create"/>
<OPTION LABEL="export app" VALUE="app"/>
<OPTION 
</CHOICE>
</CAPTION>
<CAPTION LABEL="JRuby Opt">
<TOGGLE LABEL="jruby-complete" VARNAME="jruby" DEFAULT="FALSE"/>
</CAPTION>
</UI>

<COMMANDS>

<COMMAND SHELL="System" CONFIRM="FALSE">
<!-- cd to working dir -->

   buf = new StringBuilder("cd ");
   buf.append(MiscUtilities.getParentOfPath(buffer.getPath()));
   buf.toString();

</COMMAND>



<COMMAND SHELL="System" CONFIRM="FALSE">

   buf = new StringBuilder(rp5path);
   buf.append("rp5 ");
   if (jruby){
   buf.append("--nojruby ");
   }
   buf.append(type);
   buf.append(" ");
   switch(type){
   case "run":
   case "watch":
       buf.append(file);
       break;
   }
   buf.toString();

</COMMAND>


</COMMANDS>
</COMMANDO>

F.P.S esfera.rb

frame	jdk7	jdk8
30	3.28216	3.78027
60	3.74940	4.49563
90	4.43314	6.03558
120	4.28747	6.36669
150	4.32380	6.30815
180	4.29745	6.16097
210	4.32281	6.37150

The above table was generated by capturing fps at 30 frame intervals (so is not entirely fair), and what you don't see cf watching the sketch running live, is a slightly faster start, followed by a pronounced slowdown (presumably when the optimization kicks in). Following a bit of experimentation best results were obtained with -XX:+TieredCompilation option alone 7+ fps with jdk8.

Time to give up on the Mac

I have started a new development fork of ruby-processing, I am calling it JRubyArt, there will be no support for the Mac (in the foreseeable future, possibly never, depends on active co-operation Mac users). Calling it JRubyArt may not be so daft because the end point need not only be a processing sketch (PovRAY or Sunflow).
It is an absolute requirement of the development branch to be using at least java-7 (this is requirement for processing-2.1+, but I am really targeting java-8). The idea is that JRubyArt keeps step with jruby-9000 development (which will likely require at least java-7, but likely to work best with java-8). On this basis, there is absolutely no point in supporting the Mac, which post Maverick seems to be designed not to work with java (having said that many jruby users have Macs go figure).

Promise for the future of jruby, ruby-processing

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