Author Archives: Stephen Bannasch

Serious Performance Regression in Firefox 18 and newer

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.

See: 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:

Accessing Sensor Data from Java

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)[].

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.

Crowd Sourcing JavaScript Performance-testing lets you write two equivalent ways to accomplish something in JavaScript and it then measures how fast each method is in every browser you run the test in. Other people’s performance tests can be browsed here Browse test cases.

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.

Comparison of Ruby 1.8.6 1.9 and JRuby running on Java 1.5 1.6 and 1.7

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.

Ruby Merge Sort Speed Comparison

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