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

High CPU usage in pygame #331

Open
illume opened this Issue Mar 13, 2017 · 29 comments

Comments

Projects
None yet
@illume
Copy link
Member

illume commented Mar 13, 2017

Originally reported by: Maksym Planeta (Bitbucket: mplaneta, GitHub: mplaneta)


Hello,

I have a following snippet of code:

#!python


pygame.init()
import time
time.sleep(50)

When the scripts goes sleep, I observe high CPU utilization.

I tracked this down to sound system, and when I add pygame.mixer.quit() after init, script utilizes CPU as expected. I figured out that pygame creates a new process, which eats up all the CPU and the backtrace of this thread looks as follows (this is how I pointed problem to sound mixer):

(gdb) bt
#0  0x00007f297504554d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f295e16107e in ?? () from /usr/lib/x86_64-linux-gnu/libasound.so.2
#2  0x00007f295e165fb8 in ?? () from /usr/lib/x86_64-linux-gnu/libasound.so.2
#3  0x00007f295e1a60c8 in ?? () from /usr/lib/x86_64-linux-gnu/libasound.so.2
#4  0x00007f29748c9fc5 in ALSA_PlayAudio (this=0x5633de70d990) at ./src/audio/alsa/SDL_alsa_audio.c:321
#5  0x00007f297489ed90 in SDL_RunAudio (audiop=audiop@entry=0x5633de70d990) at ./src/audio/SDL_audio.c:215
#6  0x00007f29748a6f58 in SDL_RunThread (data=0x5633de686360) at ./src/thread/SDL_thread.c:204
#7  0x00007f29748e79d9 in RunThread (data=<optimized out>) at ./src/thread/pthread/SDL_systhread.c:47
#8  0x00007f2975e5a424 in start_thread (arg=0x7f295622e700) at pthread_create.c:333
#9  0x00007f297504e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Python version: 3.5.3
libasound2 version: 1.1.3-4 (Debian testing)


@illume

This comment has been minimized.

Copy link
Member

illume commented Mar 13, 2017

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


I can reproduce this if I install from a wheel from PyPI, but not if I install pygame from source. That points to some error with the packaging - maybe an issue with the old ALSA library that it's built with. Possibly we need to try building a newer version of ALSA from source.

@illume

This comment has been minimized.

Copy link
Member

illume commented Mar 18, 2017

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


I was hoping building with a newer version of ALSA (pull request https://bitbucket.org/pygame/pygame/pull-requests/77/build-alsa-lib-ourselves-in-docker-base/diff) would fix this, but it does not seem to, unfortunately. I'm not sure what else to try.

@illume illume added this to the 1.9.x milestone Mar 26, 2017

@astronerdnj

This comment has been minimized.

Copy link

astronerdnj commented May 5, 2017

Hi there,

I have exactly the same problem running Pygame 1.9.3 with Python 3.5.2 under Ubuntu 1.6.04 LTS. All I have to do is pygame.init() and the CPU utilization shoots up drastically. I tried following this with pygame.mixer.quit() but it made no difference. I believe I installed Python using PIP3.

Just wondering if you have made any progress on the issue and/or have any ideas on what I should do?

Thanks

@takluyver

This comment has been minimized.

Copy link
Member

takluyver commented May 5, 2017

I think you can work round it by building pygame yourself from source. I haven't made any progress in working out what the problem is.

@davidshumway

This comment has been minimized.

Copy link

davidshumway commented May 6, 2017

Noticing this behavior as well: Roland00111/Trumpocalypse#18.

@steckelj

This comment has been minimized.

Copy link

steckelj commented May 18, 2017

I also have this behavior on a pi, however the pygame.mixer.quit() does not resolve the problem. Does anyone have a good link on building from source on raspbian?

@davidshumway

This comment has been minimized.

Copy link

davidshumway commented May 18, 2017

@steckelj One solution was maybe to not use pygame.init(). Are you using this? If so, try not doing so. Instead, do pygame.___.init() for any modules that are required. Such as pygame.display.init() and pygame.mixer.init() and pygame.font.init(). If you are interested see https://github.com/Roland00111/Trumpocalypse/blob/master/UI/Trumpocalypse.py for implementation.

@steckelj

This comment has been minimized.

Copy link

steckelj commented May 18, 2017

I am actually only using pygame.display.init(). I read many guides on the high CPU utilization before I posted on the issue here, and I have no loop and am just sitting at pygame.event.wait() with no allowed events and have near 100% CPU. No other updating. Is it possible I'm not experiencing the same issue?

I'll have to try a test pygame.display.init() only and see if I get the same thing.

I did find what looks to be good instructions for building from source, see pygame section here: http://elinux.org/RPi_Debian_Python3
(I have yet to test the instructions)

@davidshumway

This comment has been minimized.

Copy link

davidshumway commented May 18, 2017

Okay. Yes, for us it was similar. One solution was to use pygame.time.wait(0) in the while loop. See here: https://github.com/Roland00111/Trumpocalypse/blob/master/UI/eventsloop.py.

        while event_loop:
            self.process_pygame_events()
            pygame.time.wait(0)

Where process_pygame_events() is a function where pygame.event.get() is looped through.

Another solution may be related to clock tick() or fps.

@steckelj

This comment has been minimized.

Copy link

steckelj commented May 18, 2017

I had been through all of that above - definitely thought it was me for two weeks before I arrived here at this bug and read through everything I could find. I actually eliminated any loop entirely to be sure it wasn't that.
However, I will better confirm I am experiencing this issue before I post anything further here.

@steckelj

This comment has been minimized.

Copy link

steckelj commented May 19, 2017

I believe I can now confirm this is happening even if you only init the display. Can anyone suggest a previous version I can use? Will that avoid the problem?

The following code produces near 100% CPU on a Pi:

import pygame
pygame.display.init()
pygame.event.set_allowed(None)
pygame.event.wait()

Adding the pygame.mixer.quit() also doesn't help (I didn't init it anyhow). I also tried removing pygame and compiling from source via the following but still experience the same issue. The instructions below specified that sound had been removed.

GET PYGAME SOURCE CODE
sudo apt-get install mercurial
hg clone https://bitbucket.org/pygame/pygame
cd pygame

INSTALL DEPENDENCIES
sudo apt-get install libsdl-dev libsdl-image1.2-dev libsdl-mixer1.2-dev libsdl-ttf2.0-dev
sudo apt-get install libsmpeg-dev libportmidi-dev libavformat-dev libswscale-dev

BUILD AND INSTALL PYGAME
python3 setup.py build
sudo python3 setup.py install

Any help to get around this for the moment would be much appreciated!

@takluyver

This comment has been minimized.

Copy link
Member

takluyver commented May 19, 2017

I think there are a couple of different bugs in play here; the original one reported appeared to be only an issue with the pre-built wheels, and went away when I built pygame from source on the target system. The new one doesn't. Unfortunately I don't have any recommendations for either right now.

@Duality4Y

This comment has been minimized.

Copy link

Duality4Y commented Oct 28, 2017

I observed high cpu load too, from the package installed via pip,
but when i installed from source it was all fine.

@nylocx

This comment has been minimized.

Copy link

nylocx commented Dec 15, 2017

Hi I have the same issue on Arch-Linux and I can fix it with not initializing the mixer module.
Some Version info that could be important:
Python 3.6.3
pygame==1.9.3 (from pip! It works with the arch packaged pygame 1.9.3)
sdl 1.2.15-9
portmidi 217-5
sdl_image 1.2.12-4
sdl_ttf 2.0.11-4
sdl_mixer 1.2.12-5

@VladMasarik

This comment has been minimized.

Copy link

VladMasarik commented Jan 21, 2018

Hey there I seem to have same problem.
I used
python3 -m pip install pygame --user
to install pygame as said on pygame website.

import time
import sys
sys.path.append('/usr/local/lib/python2.7/dist-packages')
from pygame import mixer
mixer.init()
time.sleep(10)
mixer.quit()

CPU usage jumps to 90% after mixer.init() and decreases right after mixer.quit()
Off-topic... any Idea why I don't have /usr/local/lib/python2.7/dist-packages in sys.path by default and so I have to append it explicitly before I can use pygame?

@takluyver takluyver referenced this issue Feb 11, 2018

Closed

pygame 1.9.4 release #390

34 of 36 tasks complete

@illume illume modified the milestones: 1.9.x, 1.9.4 Feb 12, 2018

@illume

This comment has been minimized.

Copy link
Member

illume commented Feb 13, 2018

I noticed this issue with fluidsynth and pulseaudio. Worth investigating to see if this is the cause: FluidSynth/fluidsynth#338

@illume

This comment has been minimized.

Copy link
Member

illume commented Feb 20, 2018

Another "high cpu" issue on Ubuntu launchpad, with pulse audio in the traceback https://bugs.launchpad.net/ubuntu/+source/pygame/+bug/1314377

@illume

This comment has been minimized.

Copy link
Member

illume commented Feb 27, 2018

This is a fluidinfo/pulseaudio/SDL_mixer issue, and best addressed there.

We have the option of not including fluidsynth, but then music wouldn't work for some people.
App side, a work around of using alsa SDL audio driver with an environment variable, or not initialising the music mixer if not using it.

@illume illume modified the milestones: 1.9.4, 2.0 Feb 27, 2018

@tomkc

This comment has been minimized.

Copy link

tomkc commented Feb 28, 2018

Same issue here on Manjaro with Python 3.6.4. Got around 25% CPU usage with sampled script when using pygame 1.9.3 installed using pip. When switched to pygame 1.9.3-2 builded from Arch's source repositories everything looks fine - CPU workload drops to ~1%.

@d4em0n

This comment has been minimized.

Copy link

d4em0n commented May 18, 2018

same issue with pygame 1.9.3, my cpu temperature goes up immediately

@iErcann

This comment has been minimized.

Copy link

iErcann commented May 21, 2018

same issue with Debian 9.4, i have 25% CPU usage with the most basic pygame script possible

@oooobi

This comment has been minimized.

Copy link

oooobi commented May 21, 2018

@WeavingBird1917

This comment has been minimized.

Copy link

WeavingBird1917 commented Jun 23, 2018

Can confirm same results, and using pygame.display.init() instead of pygame.init() or pygame.mixer.quit() after pygame.init() seems to have solved the high CPU problem for me. Also, I followed all the steps exactly from the manual compile page, but still get an error on install, is there a problem with that?

@amloewi

This comment has been minimized.

Copy link

amloewi commented Aug 8, 2018

OSX High Sierra, pygame==1.9.5.dev0, anaconda python 3.6.

Installing from source, either github, or homebrew, doesn't work, pygame.display.init() doesn't work, pygame.mixer.quit() doesn't work -- just goes straight to 100% CPU.

EDIT: BUT -- and I don't know if this is feasible with other people's applications, but -- the second I switched from using pygame.event.get() to pygame.event.wait(), usage dropped from 100% to 6%. I assume most people have more events than I do, but it has also been the only thing that worked.

@illume illume referenced this issue Aug 20, 2018

Open

pygame 1.9.5 release #495

1 of 35 tasks complete
@e1000

This comment has been minimized.

Copy link

e1000 commented Aug 25, 2018

Hello,

I don't know if it helps, but on debian strech :

  1. I have the bug with pip / Python3.5 ; the high-CPU comes up with just calling mixer.init :
Python 3.5.3 (default, Jan 19 2017, 14:11:04) 
[GCC 6.3.0 20170118] on linux
>>> import pygame
pygame 1.9.4
Hello from the pygame community. https://www.pygame.org/contribute.html
>>> pygame.mixer.init()
>>> 
  1. I can't repeat the bug with python-pygame 1.9.1release+dfsg-10+b2 & (Python2)
  2. I also can't repeat it with pygame installed from source Python2
@illume

This comment has been minimized.

Copy link
Member

illume commented Aug 25, 2018

@e1000 Good detective work.

Yeah, it's a sdl_mixer issue for sure. I think it's to do with the SDL and SDL_mixer that are linked in the wheel. As you and other people state: the issue does not appear with Arch linux compiled SDL and pygame, or when you compile pygame from source and link against the Arch linux supplied dependencies.

I feel we might be able to apply all the patches that arch linux does (and more), and this would fix the issue.
See the issue here which is about applying the patches: #497

If you feel like making the wheels yourself, please see in the pygame repo, the instructions and scripts to automate building it all are there: buildconfig/manylinux-build/

If none of the patches fix the issue, then it may be to do with config, or even some sort of ABI incompatibility of the ancient linux that the manylinux wheels are made on.

@mathias93

This comment has been minimized.

Copy link

mathias93 commented Nov 24, 2018

Same issue installed 1.9.4 using pip, python 3.4 @ 100%CPU utilization
Confirmed on desktop Ryzen7 using python 3.5.3 as well

@kooscode

This comment has been minimized.

Copy link

kooscode commented Dec 9, 2018

same issue with python 3.6.3 and installed with pip3.

100% CPU pegged with this code..

import pygame
import time

pygame.init()

while True:
    time.sleep(1)

but works perfect when calling pygame.mixer.quit like so..

import pygame
import time

pygame.init()
pygame.mixer.quit()

while True:
    time.sleep(1)
@SebastianJL

This comment has been minimized.

Copy link

SebastianJL commented Dec 10, 2018

I appear to have the same problem.
2 cores have 100% usage if I use:

pygame.init()

The cpu usage drops down to about 20% on only one core if i use:

pygame.init()
pygame.mixer.quit()
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment