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

Already on GitHub? Sign in to your account

ipython-qtconsole uses 100% CPU #588

Closed
rgaudette opened this Issue Jul 17, 2011 · 13 comments

Comments

Projects
None yet
6 participants

Hi,
When I run ipython-qtconsole.exe, I observe 100% CPU usage (really 50% on my dual core machine) when nothing is running in the console. My machine consists of the following configuration:
Windows 7 64 bit
Python 2.7.2 64 bit binary install (from python.org)
PyQT and QT from Christoph Gohlke 's binary distribution PyQt-Py2.7-x64-gpl-4.8.4-1.exe

I first observed this behavior on Christoph Gohlke 's ipython-0.11.dev.win-amd64-py2.7.exe. I then uninstalled that package and pull the latest IPython from github. The latest version still exhibits the 100% CPU usage behavior on my machine.

Some other observations that might be helpful:

  • If I close the QT console window but leave the kernel running (selecting "No, just this console button"), the CPU usage stays at 100%.
  • The windows console based ipython.exe does not have this behavior on my machine.
  • Task manager shows that it is pythonw.exe using the CPU

Sharpie commented Jul 17, 2011

Now that I read your bug report, I recall this happened to me the other day. Saw a pythonw.exe in the task manager using 25% of the available CPU (one out of four cores) after using the ipython-qtconsole.

Similar setup:

Windows 7 64 bit
EPD 7.1

Owner

fperez commented Jul 17, 2011

Says @epatters on-list:

It would be helpful to know whether the CPU utilization is pylab-specific. I suspect the trouble may be there.

Sharpie commented Jul 17, 2011

Unless the ipython-qtconsole included in EPD 7.1 64 bit starts pylab by default, I'm not using it.

Owner

minrk commented Jul 17, 2011

For reference, can you see if the same thing happens when you start the qtconsole in the normal ipython qtconsole (non-guiscript) way?

No, the qtconsole does not do any pylab imports by default, but it could be related to the polling, which is different for with and without pylab integration. Does it happen if you do use --pylab?

Sharpie commented Jul 17, 2011

For reference, can you see if the same thing happens when you start the qtconsole in the normal ipython qtconsole (non-guiscript) way?

Yes. Still get 100% usage on one core. The only difference is that python.exe is the active process instead of pythonw.exe.

No, the qtconsole does not do any pylab imports by default, but it could be related to the polling, which is different for with and without pylab integration. Does it happen if you do use --pylab?

Good thinking! ipython-qtconsole --pylab and ipython qtconsole --pylab both idle at negligible CPU usage.

Owner

minrk commented Jul 17, 2011

Great, thanks! That probably means it's the zeromq poller that's not properly idle. Possibly a units issue on Windows.

What if you do:

ipython qtconsole --Kernel._poll_interval=10000

?

With my installation, there is negligible CPU usage with ipython.exe and ipython.exe --pylab.

Usage of 100% of a core with the following command lines
ipython-qtconsole.exe
ipython.exe qtconsole
ipython-qtconsole.exe --pylab
ipython.exe qtconsole --pylab

So it appears that not pylab specific with my installation. Let me know if there is anyway I can get you more information about what the process is executing.

@rgaudette rgaudette closed this Jul 17, 2011

@minrk minrk reopened this Jul 17, 2011

Owner

minrk commented Jul 17, 2011

@epatters it's actually the WindowsParentPoller. On 64b Windows, there is a line that specifies ctypes.c_int that should be ctypes.c_int64 on x64. The result is the WaitForMultipleObjects call is failing every time, but inside a while True, so it's just failing repeatedly as fast as it can. I'll do a PR shortly.

minrk added a commit to minrk/ipython that referenced this issue Jul 17, 2011

handle different pointer size on x64 Windows
WindowsParentPoller makes a winapi call, and needs to handle
32/64b pointer difference.

This commit adds switching of c_int vs c_int64, depending on
platform.architecture().

It also prevents hogging CPU by adding a short sleep in possible
cases where the call still fails.

closes gh-588
Owner

minrk commented Jul 17, 2011

Try the code from here: #589

It fixes the problem on my 64b VM, and if there are other combinations of platform or version that still cause a similar error, it won't throttle the CPU anyway (instead, the parent poller will just not work).

Sorry for the accidental close, I am new to github.

Nice, that fixed it all the cases I described above.

Thanks!

Contributor

epatters commented Jul 18, 2011

Great! Nice catch @minrk.

Owner

fperez commented Jul 18, 2011

On Sun, Jul 17, 2011 at 7:23 PM, epatters
reply@reply.github.com
wrote:

Great! Nice catch @minrk.

@minrk, awesome job, as usual. Thanks for jumping on this!

f

@minrk minrk closed this in c279fd1 Jul 18, 2011

@minrk minrk referenced this issue Jul 18, 2011

Closed

issue 588 #589

mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this issue Nov 3, 2014

handle different pointer size on x64 Windows
WindowsParentPoller makes a winapi call, and needs to handle
32/64b pointer difference.

This commit adds switching of c_int vs c_int64, depending on
platform.architecture().

It also prevents hogging CPU by adding a short sleep in possible
cases where the call still fails.

closes gh-588

mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this issue Nov 3, 2014

dbiery commented Oct 22, 2015

I recently ran into this issue when following a video on installing anaconda etc. Can anyone provide instructions on how to implement the code that minrk wrote to fix the problem. I just started trying to use python and am definitely a novice (I spend most of my time doing stats coding and not configuring programs) so I'm a bit out of my depth with fixing this.

Any help would be greatly appreciated! Thanks in advance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment