there is 28% (12.5 fps) performance drop in Controls.TableView-Keyboard-table30x150-press1 happened
in controls-scrum build #350 comparing to b347. The performance dropped from 45.9 fps to 33.3 fps.
45.9 fps were observed starting from build #328 till #347. So, what we have looks as:

 318-327: 33.5 fps
 328-347: 45.9 fps
     348: 17.7 fps
     350: 33.3 fps

Steps to run the test:
 > cd tests/performance/Controls
> ant
> java -cp "${JFX}/rt/lib/jfxrt.jar;../../../import/benchmarks-2.1.1/benchmarks-2.1.1.jar;../FXBenchmark/dist/FXBenchmark.jar;./dist/Controls.jar"
   controls.bm.TableViewBenchmark -i 3 -wt 5 -tr 15 -mode keyboard -usePulse true -keysPerInjection 1 -cells 150


Link to Aurora results:
 http://aurora.russia.sun.com/performance/faces/ChessBoard.xhtml?reportName=FX2-controls-scrum&parameters=%5Bshownbenchmarks%5D%281%3D1%29%5Brefrelease%5D2.0%5Brefbuild%5D%3D+%27347%27%5Brefjdkrelease%5D1.6.0_23%5Brelease%5D%28pr.product.productRelease+IS+NOT+NULL%29%5Bbuild%5D%28pr.product.build+%3D+%27347%27%29OR%28pr.product.build+%3D+%27350%27%29%5Bjdkrelease%5D%28jdk.product.productRelease+IS+NOT+NULL%29&splitting=%5BX+axis%5DfxConf%2C+metricName%5BComplement%5Dbenchmark%2C+jdkBuild%2C+jdk%5BY+axis%5DbenchmarkName%2C+benchmarkConf%2C+fxRelease%2C+fxBuild%5BZ+axis%5Dos%2C+hwclass%2C+jdkRelease%2C+benchmarkSuite&reference=%5BOthers%5DfxRelease%2C+fxBuild%2C+jdkRelease%2C+jdkBuild%2C+jdk%2C+benchmarkSuite%2C+benchmarkName%2C+metricName%5BReference+Set%5Dbenchmark%2C+os%2C+benchmarkConf%2C+fxConf%2C+hwclass&mixReference=false&flags=&significance=empty&hideDataConfiguration=false&calculateSummary=false&showSummaryExpanded=false&showSummaryContents=true&showComplementAttributes=false&compactTables=true&viewStyle=chessboard&filter=


Comments from Jonathan:

> Ah - interesting, thanks for pointing that out!
>
> Initially I thought it could be the changes made for RT-15978. The initial commit (that is part of #348) had a bad println call which, as we've seen previously, has a
> serious impact on fps. However, the println was also removed in #348, so that won't likely be it.
>
> Now I think it is the changeset made for RT-15986. This changeset means we eagerly calculate the number of visible cells in the virtual flow (which is something Oleg and I
> worked to reduce). If this can be confirmed then I'm happy to try and improve the performance of this method. Feel free to file a bug with your findings.
>
> Thanks for keeping us honest (and performance up!) :-)
>
> -- Jonathan
>
>
> On 18/08/2011 4:59 p.m., Ekaterina Pavlova wrote:
>> On 8/17/11 11:53 PM, Jonathan Giles wrote:
>>> Looking at the changes in hudson for each build, I'm not sure why build #348 led to such a drop.
>>> The only change in that build was the addition of a number of unit tests.
>>
>> this is what shown here:
>> http://jfx.sfbay.sun.com/hudson/job/presidio-controls-scrum/348/
>>
>> but if you click on windows you will see that the list of changes is bigger:
>> http://jfx.sfbay.sun.com/hudson/job/presidio-controls-scrum/348/label=windows-i586-14/
>>
>>> These would have no impact on performance. #349 was another test-only change,
>>> and #350 looks like it was our repo sync from master which might have gained us some
>>> performance improvements from general graphics cleanups.
>>>
>>> Going back the other way, #347 only had one change to 'Use class.getResource to load the stylesheet' by Kinsley, but it only touched three demo apps, so that won't be
>>> responsible.
>>>
>>> In other words, I'm not sure what caused this drop-off in performance. If you're sure the performance of #346 and #347 is good, there is no clear sign in the hudson change
>>> logs about why the performance should drop off like this.
>>>
>>> -- Jonathan