The Firefox performance regression introduced into the codebase on 2012-09-29 and present in FF v18, v19, and Nightly versions is much more serious than I previously thought.
Basically FF versions after v16 are now almost unusable running NextGen models of any complexity for longer than 30s.
Firefox Performance Comparison 20131902 and Confirmation of FF slowdown over time.
There are several active Mozilla issues that people are working on. This is my original bug report:
And the other bug reports resolving this issue depends on:
For years we have been using several layers of Java, Java Native Interface, and native driver code to support common access to sensors from multiple Probeware interfaces from different vendors. We’ve been calling these layers the org-concord-sensor framework.
Our Java/OTrunk framework which has supported many kinds of interactive educational activities uses the org-concord-sensor framework to route data from sensors to real-time graphs and as input into dynamic models.
The Google Code org-concord-sensor project includes a link to a some older (but still useful) documentation in our Confluence wiki Sensor Device System.
Here’s a general page in our wiki which shows how to (setup a full development environment for OTrunk in Eclipse)[http://confluence.concord.org/display/CSP/Setup+Development+Environment].
Recently we have adapted this framework to support collecting data from Vernier GoIO probes directly in the browser.
If you have a GoMotion probe try the GoMotion Graph Demo page.
Taking a look at a specific test could show data where you might want to pick an approach that is 25% slower in Chrome …
For example operator-vs-localecompage shows that FireFox starts out seven times slower than Chrome and the slower method in Chrome runs twice as fast in FireFox as the faster method in Chrome.
Other people who view your test can contribute new results when it is run in their browser also.
Ruby is a powerful and dynamic open-source object-oriented language we have been using extensively at CC in the last few years for the web applications that manage and coordinate authoring and deployment of activities based on the SAIL/OTrunk framework .
The standard Ruby VM is written in C and we’ve been using version 1.8.6, the latest stable release on our servers. A beta version of the next major release, version 1.9.1 has recently been released.
Ruby 1.9 looks to be about twice as fast as Ruby 1.8.6.
I’m even more impressed by the recent performance increases in JRuby however. This is a version of Ruby that runs in Java. Programs written in JRuby can easily access code written in Java which makes integration with the rest of our Java codebase much easier.
A year ago programs written in JRuby were often slower than ones written in version 1.8.6 of C Ruby. Now for some benchmarks JRuby is twice as fast as Ruby 1.9.
More details about some of these measurements are here:
Ruby 1.8.6, 1.9, and JRuby running on Java 1.5, 1.6, and 1.7 compared
The next version of Java being developed is v1.7.0 and the OpenJDK version is being released as open source under the GPL license.
I’ve written a wiki page describing how to build and install this new version of Java on Mac OS 10.5.6.
Build OpenJDK Java 1.7.0 on Mac OS X 10.5