iPad3 performance is dismal

[samreid]

Built version. Dragging around a single battery => 15fps Battery+resistor+wire => 20fps

@ariel-phet I'm not sure I should be using the iPad3 as my baseline performance test for this sim. What do you recommend?

[ariel-phet]

@samreid we often test on the iPad3 to flesh out performance concerns, but baseline performance for the published sim should be tested on iPad2

[samreid]

@phet-steele can or one of your colleagues please check iPad2 performance for http://www.colorado.edu/physics/phet/dev/html/circuit-construction-kit-dc/1.0.0-dev.11/circuit-construction-kit-dc_en.html?profiler&screens=1 for the cases described in the issue description? I'm trying to gauge how the performance differs between iPad2 and iPad3 for this sim.

[phet-steele]

Running http://www.colorado.edu/physics/phet/dev/html/circuit-construction-kit-dc/1.0.0-dev.11/circuit-construction-kit-dc_en.html?profiler&screens=1 on an iPad 2 iOS 9.3.5:

Dragging around a single battery => 18-20fps Battery+resistor+wire => Depending on the length of the wire:

• 23fps (long)
• 30fps (short)

[samreid]

Thanks @phet-steele, it looks like the iPad3 and iPad2 performance are pretty similar. If there's time, I'd like performance to be profiled/investigated before 1.0.

[arouinfar]

Discussed in 5/4/17 design meeting. KP recommends that @samreid spends 2 days investigating performance. @jonathanolson won't likely have the availability to work with SR until later this summer. The goal for now would be for @samreid to continue to render things in scenery with some possible refactoring. Moving to WebGL is also a possibility, but would be a much bigger effort.

[samreid]

I can get the performance of dragging a single battery up to 20fps (up from 15fps) if I skip electron relayout in fixed length components. However, I don't have it working quite right and electrons are disappearing and spreading out.

[samreid]

The above commit only lays out electrons in circuit elements with a wire, which speeds up battery-dragging to 19fps. However, it seems less robust and I bet @phet-steele can figure out how to break it.

[samreid]

I tested a current version of DC on my iPad3 today and it felt usable to me. Have I lowered my standards? Is it actually better? How much effort should be put into this? Would be good to discuss at design meeting.

[samreid]

@jonathanolson can we please schedule an appointment to work on CCK performance?

[samreid]

@jonathanolson and I discussed the following possibilities:

• [x] Combine light rays into a single path, one is in the navbar
• [x] Font awesome node in VertexNode, removeChild
• [x] possibly same thing for ValueNode, don't have it be a child when
• [ ] Memory profiling, lots of churn when dragging battery
• [ ] Try getting rid of intermediate node in ChargeNode
• [ ] use setInSceneGraph for fire and wire highlights
• [ ] use translation instead of center?
• [ ] try tethering ipad and looking for performance stats

We will continue tomorrow.

[Denz1994]

Combine light rays into a single path, one is in the navbar

Fix See issue: https://github.com/phetsims/scenery-phet/issues/309

Testing on iPad3 FPS status: 19fps -->19fps (also used screens=1 and found similar results)

[Denz1994]

Font awesome node in VertexNode, removeChild

Fix A util function was provided to check if the cutButton needs to be added/removed from the scene graph. This check makes sure that the cutButton isn't being moved with the circuit element when it is not displayed.

Testing on iPad3 FPS status: 19fps --> 19.5fps (toggles between 20fps and 19fps)

[samreid]

After applying the same strategy to Vertex.highlightNode, performance remains steady at 19fps.

[samreid]

possibly same thing for ValueNode, don't have it be a child when

Fix We used setInSceneGraph for CircuitElementNode and ValueNode

Testing on iPad3 FPS status: around 21fps

[samreid]

When tethered, Safari tells me that most of the time is being spent in handling the touch event:

That is about 60 milliseconds, but of course things are much slower when tethered.

[samreid]

Looks like 10% of the JS time is getting used in validatePointers.

[samreid]

DragVertex could get a speed boost:

[samreid]

It looks like ObservableArray is wrecking performance if we use toArray afterwards:

[samreid]

Still around 21fps after the change above.

[samreid]

For WireNode, a custom (rectangular) hit area may speed things up.

[samreid]

@jonathanolson pointed out that it is odd that we are getting a low frame rate when the threads aren't even maxed out... There are gaps in the phases which may be caused by the act of recording the data.

[samreid]

• [ ] only update cutButton position when it is visible

[samreid]

• [ ] Can set Text or other nodes to have their center at zero (with a new intermediate node in the tree), then we can use setTranslation (fast) instead of setCenter (slow). This will work best when the text is not changing every frame.

[samreid]

My hope is that Safari is throttling the frame rate to 20-30 frames a second to keep it consistent, and that if we can speed up enough we will pass a threshold to jump to a higher frame rate.

[samreid]

After the above changes, I'm seeing 22fps on iPad3 (and once a 23fps!).

[samreid]

I removed everything from the scene graph except one battery and its toolbox and still seeing around 23fps.

[samreid]

Commenting out ChargeAnimator and ChargeLayout gets close to 30fps

[samreid]

Chrome reports about 10MB/s in garbage. Compare this to blast which has 0.7MB/s while animating.

1.3MB/sec in Function Builder Basics (which gets 30fps on iPad3).

[samreid]

6.4 MB/sec is baseline, when commenting out body of getDropTarget, this drops to 5MB/sec. So getDropTarget should be improved.

[samreid]

• [ ] use imageOpacity where possible, or put the transparency into stroke or fill

[samreid]

Putting mainLayer as 'webgl' gives 47 frames per second with electrons animating. I'm dragging a battery at 57 frames per second.

This version has webgl batteries and resistors and electrons: http://www.colorado.edu/physics/phet/dev/html/circuit-construction-kit-dc/1.0.0-dev.67/circuit-construction-kit-dc_en.html

I am very excited to finally see good performance on the iPad for this sim. We could rasterize everything in the webgl layer (like vertex nodes, solder, etc.). Readouts would be tricky. There is a timing hitch when dragging something out of the toolbox. There will be many corner cases. But this seems like a good thing to investigate if/when there is time.

[samreid]

@jonathanolson and I added some synthetic garbage like this:

      var self = this;
      // create garbage
      for ( var i = 0; i < 100000; i++ ) {
        this.test( (function(  ) {
          self.temp = i;
        }) );
      }

This reduced resting frame rate on ipad from 60fps to 50fps. Chrome reports 100MB/sec getting garbage collected but it isn't slowed down too much.

Hence searching for and eliminating excess memory allocation in our simulations may not have a significant impact on the user experience. (Unless we see GC stutters after performance is otherwise smooth from webgl fixes).

[samreid]

I rasterized some circles and switched to use imageOpacity, now the performance without webgl is up to about 24fps (42ms/frame).

[samreid]

We switched to WebGL in #367 and that made a huge difference. We also worked specifically on performance when dragging an object out of the toolbox in #369. WebGL has been more work to implement and will complicate some AC and basics features (if we now want to draw all circuit elements in WebGL), but it seems like a dramatically improved user experience on slow platforms. Continuing in other open issues.