Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8119034

28% (12.5 fps) performance drop in Controls.TableView-Keyboard-table30x150-press1 in controls-scrum b350 vs b347



      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:

      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




            • Assignee:
              jgiles Jonathan Giles
              epavlova Ekaterina Pavlova
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: