Howdy, Stranger!
We are about to switch to a new forum software. Until then we have removed the registration on this forum.
Categories
- All Categories 25.7K
- Announcements & Guidelines 13
- Common Questions 30
- Using Processing 22.1K
- Programming Questions 12.2K
- Questions about Code 6.4K
- How To... 4.2K
- Hello Processing 72
- GLSL / Shaders 292
- Library Questions 4K
- Hardware, Integration & Other Languages 2.7K
- Kinect 668
- Arduino 1K
- Raspberry PI 188
- Questions about Modes 2K
- Android Mode 1.3K
- JavaScript Mode 413
- Python Mode 205
- Questions about Tools 100
- Espanol 5
- Developing Processing 548
- Create & Announce Libraries 211
- Create & Announce Modes 19
- Create & Announce Tools 29
- Summer of Code 2018 93
- Rails Girls Summer of Code 2017 3
- Summer of Code 2017 49
- Summer of Code 2016 4
- Summer of Code 2015 40
- Summer of Code 2014 22
- p5.js 1.6K
- p5.js Programming Questions 947
- p5.js Library Questions 315
- p5.js Development Questions 31
- General 1.4K
- Events & Opportunities 288
- General Discussion 365
In this Discussion
- davidrea July 2017
- jeremydouglass July 2017
Processing.py on Mac consuming battery and hanging computers
I'm teaching a course using Processing.py and two of my students are having chronic problems with Processing. It seems to consume a lot of CPU and drains their battery quickly. Performance also degrades, with longer and longer times needed to start up sketches until they restart their machines.
When we look in Activity Monitor there are various processes called "Processing" in there, even when no sketches are running. Is it possible that Processing is spawning processes that aren't getting killed when the sketches are closed?
One student is on Sierra, the other on Yosemite.
Tagged:
Answers
This sounds familiar. Could possibly be related to:
https://github.com/jdf/processing.py/issues/233
But if not, perhaps have a student open a detailed issue on github?
https://github.com/jdf/processing.py/issues
I don't think it's related; my students aren't using shapes yet, just the basic polygons and lines. Unless the problem described can be replicated even more simply.
I believe that Processing.py does spawn a Jython runner that it leaves running across multiple plays of a sketch, and only closes when the sketch is completely closed. This is to avoid very long Jython startup times on each run.
So that runner could be failing to close for some reason when a sketch closes -- or a sketch could be creating a new runner every they hit play, which it isn't supposed to do. Your students could watch the process list while open a new sketch, hitting run a few times, then closing it and see what is happening.