Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test for memory leaks #64

Closed
pixelzoom opened this issue Apr 6, 2018 · 8 comments
Closed

test for memory leaks #64

pixelzoom opened this issue Apr 6, 2018 · 8 comments
Assignees

Comments

@pixelzoom
Copy link
Contributor

This issue is to record the results of memory leak testing, and identify any issues.

@pixelzoom
Copy link
Contributor Author

See #86 for possible leak in the game.

@phet-steele
Copy link
Contributor

phet-steele commented May 1, 2018

@pixelzoom I went ahead and took snapshots while running https://phet-dev.colorado.edu/html/equality-explorer/1.0.0-dev.111/phet/equality-explorer_all_phet.html?fuzzMouse. Looks like you had a steep initial climb (probably from entering all the screens for the first time), but then stabilized over the remaining minutes. The larger snapshots had more things on the screen at the moment of recording, which is a likely explanation.

EDIT: after 30 & 50 min tests, might have a tiny leek.

leek

Minutes MB
0 69.1
1 81.1
2 84.8
3 83.1
4 83.7
5 82.8
6 83.9
7 86.6
8 86.3
9 86.9
10 85.5
30 87.0
50 89.3

pixelzoom added a commit that referenced this issue Jun 4, 2018
pixelzoom added a commit that referenced this issue Jun 4, 2018
@pixelzoom
Copy link
Contributor Author

pixelzoom commented Jun 4, 2018

I added query parameters locked and lockVisible, for testing memory profiling with the lock in a specific state. Not sure yet whether I'll need it, but good to have and it was easy to add.

@pixelzoom
Copy link
Contributor Author

pixelzoom commented Jun 4, 2018

Testing the Variables screen is sufficient for testing the Basics, Numbers, and Lab screens. They all use the same "code paths".

Below are Chrome 67 heap snapshots (macOS 10.11.6) for the Variables screen with ?screens=3&fuzzMouse. After 30 minutes, heap size stabilized at 27.0 MB. My conclusion is that this collection of screens has no significant memory leaks.

Minutes Heap Size (MB)
0 21.3
5 26.4
10 26.6
15 27.7
20 27.3
25 27.0
30 27.0

@pixelzoom
Copy link
Contributor Author

pixelzoom commented Jun 4, 2018

The Operations screen uses code paths not used in the Variables et al. screens. Specifically, it adds the universal operation and it combines like terms on the plates (which involves a different drag listener subtype, CombinedTermsDragListener).

Below are Chrome 67 heap snapshots (macOS 10.11.6) for the Operations screen with ?screens=4&fuzzMouse. After 30 minutes, heap size stabilized at ~30 MB. My conclusion is that this screen has no significant memory leaks.

Minutes Heap Size (MB)
0 22.0
5 28.5
10 28.7
15 29.0
20 29.4
25 29.8
30 29.9

@pixelzoom
Copy link
Contributor Author

pixelzoom commented Jun 4, 2018

The Solve It! screen shares code with other screens, but has code paths that are unique to this screen.

Below are Chrome 67 heap snapshots (macOS 10.11.6) for the Solve It! screen with ?screens=5&fuzzMouse. This screen has an overall bigger initial footprint because it contains 4 scenes (levels), and they are all instantiated at startup. After 30 minutes, heap size stabilized at ~50 MB. This test suggests that this screen has no significant memory leaks.

But... For this screen, ?fuzzMouse does not provide a good example of typical use. Specifically, we didn't solve challenges, we didn't get to the Reward, and we spent an atypical amount of time on the level-selection UI. So I'll do another test that involves playing the game manually, perhaps similar to what @phet-steele did in #86.

Minutes Heap Size (MB)
0 40.9
5 49.0
10 48.4
15 49.2
20 49.9
25 49.9
30 50.0

@pixelzoom
Copy link
Contributor Author

pixelzoom commented Jun 4, 2018

To further test the Solve It! screen, I followed a procedure similar to what @phet-steele did in #86. I manually played all 4 levels, in order. When I had solved 11 challenges (and had seen the Reward after the 10th solution) I took a heap snapshot and went on to the next level. After completing all 4 levels, I pressed the Reset All button, and took another heap snapshot. Then I repeated the entire process.

Below are Chrome 67 heap snapshots (macOS 10.11.6) for the Solve It! screen with ?screens=5. Memory did not grow appreciably, and dropped after pressing Reset All. I'm confident that this screen has no significant memory leaks.

Goal Heap Size (MB)
sim started 39.9
Level 1 completed 41.9
Level 2 completed 43.7
Level 3 completed 45.5
Level 4 completed 46.6
Reset All button pressed 45.5
Level 1 completed 45.5
Level 2 completed 45.9
Level 3 completed 46.5
Level 4 completed 47.0
Reset All button pressed 46.0

@pixelzoom pixelzoom self-assigned this Jun 4, 2018
@pixelzoom pixelzoom mentioned this issue Jun 4, 2018
97 tasks
@pixelzoom
Copy link
Contributor Author

pixelzoom commented Jun 4, 2018

Finally, I tested with all screens, using ?fuzzMouse. Below are Chrome 67 heap snapshots (macOS 10.11.6). Memory usage started at 71.1MB, reasonable for a sim with 5 screens, and stabilized at ~82MB. I'm confident that this sim has no significant memory leaks.

Minutes Heap Size (MB)
0 71.1
5 79.7
10 78.7
15 82.2
20 82.2
25 81.4
30 83.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants