Mar. 2014 JR changes come with massive performance consequences

Summary

In March 2014, the ODK JavaRosa repo was updated with a series of changes
from CommCare:

https://bitbucket.org/m.sundt/javarosa/commits/44928af52796133ee3681b6aa654d780084ae313

This seems to have corrected some thorny issues relating to when
expressions should be reevaluated, such as the one discussed here:

https://code.google.com/p/opendatakit/issues/detail?id=888

But those changes seem to come with some truly massive performance costs.

Details

In May 2014 we merged these changes into SurveyCTO, tested, and released.
Just this past week, we had a customer with a long, complex form (2,500
fields with many calculations, relevances, etc.) that had been working very
well with an old version of SurveyCTO Collect; when they upgraded to our
latest version, the performance degraded to the point of being unusable.
Form validation (when finalizing) was the worst (taking 15-20 minutes), so
we focused on that.

In our profiling of this form, a single validation pass through a
mostly-empty form took 25 seconds before and 2.5 minutes after the JR
changes. When a particular consent field gets a value, before 81
down-stream expressions (relevances, constraints, and calculations) were
re-evaluated; after the change, it shot to 784 expressions. And while
before there were cases where the logic caused the same expressions to be
reevaluated multiple times, it was 3-4 times max before -- and now it's
16-28 times for many expressions.

The new code seems to be safer and seems to be basically working -- but
it's coming at a truly massive performance cost. For small forms on fast
devices, it's no big deal. But for long forms, it's a huge deal.

Solution?

This may only be a problem for us (SurveyCTO), as I'm not sure how common
truly massive forms are in other ODK-based systems. I'd say that we,
conservatively, have at least 150 active servers with pretty massive forms.
Luckily, most of them are still running older versions since our practice
is to help users stay on old versions until they need/want to upgrade
(typically between survey rounds). So it might be that this is mostly a
SurveyCTO issue.

While we're obviously willing to put time into a solution -- we have to
(and will) solve this for our users -- JR is a component shared across most
ODK systems and it has been primarily maintained by others. I wanted to
reach out to see who, if anybody, would want to be involved in the process.
Any takers?

Or, perhaps there is already a solution off in the CommCare repo? Having
all of these different forks obviously comes at a cost..!

Thanks very much,

Chris