Memory check

[samreid]

During #395 I noticed memory usage of this sim is on the high side. Can it be reduced?

99.3MB requirejs
90.9 built

[samreid]

From slack:

Sam Reid [12:27 PM]
I just measured Wave Interference to have a 90.9MB heap size when built. Do we have a memory limit? Or did that change when we dropped iPad 2 support?

Kathryn Woessner [12:38 PM]
We generally try to keep it under 100 MB in most circumstances, but I don't know about a hard limit. The last memory test done was: phetsims/qa#238 (comment) I believe. We normally would do more after big changes, but that rc was fairly rushed.
Sorry that wasn't caught.

Sam Reid [12:54 PM]
No worries, a new screen has been added so that’s why more memory is being used

[samreid]

@ariel-phet reported this seems on the high side, would be worth an hour of investigation to (a) understand it better and (b) see if anything can be easily reduced. Also confirm there are no leaks.

[samreid]

Snapshots taken every couple of minutes shows memory is tapering off--probably not a leak:

[samreid]

To help understand where the memory is used, I took a snapshot of memory for each screen:

1: 45MB
2: 45MB
3: 36MB
4: 27MB

It seems we should focus our efforts on screens 1-2

[samreid]

I determined that Path/Shape subpaths account for 25% of the simulation size. I changed Path.setShape to always use a 100x100 rectangle and did a memory snapshot:

[samreid]

Also, I noticed every single subpath segment Line extends Events, not sure how much that increases the weight. I tried commenting all out trigger0('invalidated') and all on('invalidated') and changed Segment to no longer extend Events, and it saved around 6MB of memory.

[samreid]

Converting Segment to use TinyEmitter instead of extend Events saves around 1MB ~ 1% memory. I'll open a kite issue for that part.

[samreid]

@ariel-phet after an hour or so, I found a place where excess memory was being used in kite and proposed an improvement. It should be analyzed and reviewed by @jonathanolson before we use it in production. Can you please visit phetsims/kite#79 and recommend a priority/timeline? Also, do you want more time spent on this issue, or is it at a good stopping point?

UPDATE: one more note, the proposed change in Kite would improve other sims as well (proportional to how many shapes/subpaths they use).

[ariel-phet]

@samreid I find it suspect that the first 2 screens are both 45 MB, and the 3rd screen is nearly 10 MB less. These all have very similar functionality.

Is something like the speaker causing this big discrepancy since the speaker has many many images associated with the moving cone? If so, The cone kind of looks like it can be drawn in code with some simple shapes and gradients. So I would at least like you to spend time to identify where that extra 10 MB is coming from. If the first two screens had the same memory footprint (or similar) to the 3rd screen I would be fine closing this issue.

[ariel-phet]

Side note @samreid if you do identify the speaker being the issue, drawing the cone in code might make a nice side project for an intern since I know your time is constrained.

[ariel-phet]

@samreid it was also noted in Design meeting that the "particle view" exists on the first two screens and not on the 3rd screen. Is there something about creating the particle view that adds all this memory?

[samreid]

Here are some notes from memory analysis:

screens=1
43.8MB full
43.9MB use Node instead of Sound particle layer
43.9MB showSoundParticles is always set to false
40.3MB use Rectangle instead of SoundWaveGeneratorNode
39.8MB use Rectangle instead of WaterWaveGeneratorNode
40.1MB use Rectangle instead of LightWaveGeneratorNode
31.3MB use Rectangle instead of WaterWaveGeneratorNode, SoundWaveGeneratorNode and LightWaveGeneratorNode
43.9MB no ShadedSphereNode in WaveGeneratorNode
34.4MB no RoundStickyToggleButton or ShadedSphereNode in WaveGeneratorNode
43.9MB delete out 20 of the 21 images in SoundWaveGeneratorNode

screens=1,2
68.8MB default
62.2MB use Rectangle instead of SoundWaveGeneratorNode

screens=3
35.7MB default

SoundWaveGenerator 3.6MB
LightWaveGenerator 4.1MB
WaterWaveGenerator 3.8MB
RoundStickyToggleButtonx3 9.4MB

So it appears the SoundWaveGenerator takes up 3.6MB, but this is less than either the LightWaveGenerator or WaterWaveGenerator take. And deleting 20 of the 21 images in SoundWaveGeneratorNode does not impact the heap size. But a significant portion of the memory taken by any of the wave generators is the RoundStickyToggleButton. Combined, the 3 RoundStickyToggleButtons (one for each scene) takes a total of 9.4MB. However, I realized that PlaneWaveGeneratorNode creates one RoundStickyToggleButton for each scene, so this does not account for the difference between the scenes.

I feel like I should investigate further but wanted to write down my progress.

[samreid]

Comparing screen 1 to screen 3, I see this difference in heap allocations:

There is a 5MB difference in allocation of Vector2, Bounds2 and Line, but it is not clear where these are coming from.

I also tried switching to flat appearance in all round buttons, but that only saved around 1MB total (I believe this test was done for one screen)

Use Flat appearance instead of 3d appearance in all round push buttons.
Screens=1
42.6MB

[samreid]

I discovered that the Waves screens was creating secondary unused wave generators. In the preceding commit (before preceding comment) I removed these and saved about 5MB total. After this change, the total built sim is down to 84.5MB. @ariel-phet is this a good stopping point for 2.0?

UPDATE: Also we are hoping to save another 1MB or so in phetsims/kite#79.
UPDATE: After kite#79 applied, we are around 85MB (there is some noise in the memory levels)

[ariel-phet]

@samreid thanks for investigating further, that seems to be down to a much better level. Closing.