[GEM-dev] [ pd-gem-Bugs-3308535 ] pix_image eats a lot of CPU even when idle

SourceForge.net noreply at sourceforge.net
Wed Jun 8 13:08:22 CEST 2011


Bugs item #3308535, was opened at 2011-05-27 21:50
Message generated for change (Comment added) made by katjav
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3308535&group_id=64325

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: linux
Status: Open
Resolution: None
Priority: 8
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_image eats a lot of CPU even when idle

Initial Comment:
If you have many [pix_image] objects in a patch, even if none of them loads any image and even if none of them is connected to any gemhead, Pd will consume a lot of CPU, apparently proportional to the number of [pix_image] instances.

On a dual core machine, the amount of CPU consumption can exceed 100% of a core, so I guess the issue must be in some part of the code that is threaded - hopefully this may help to track down the issue.

The attached patch (64 pix_images) eats 150% of my intel core duo t9300 on Ubuntu 10.04 while the patch is doing absolutely nothing.


This makes it impossible to have a handful of pix_image objects with preloaded images and dynamically choose which one to show, just to name one thing that can't be done and which should not be resource-demanding. This kills any project working with images.

----------------------------------------------------------------------

Comment By: Katja  (katjav)
Date: 2011-06-08 13:08

Message:
Confirm this issue for Debian Squeeze. pix_image causes a cpu load of ~4%
per instance when thread loading is enabled.

Debian Squeeze
Panasonic CF 74 with Intel integrated 945GM
Pd-extended 0.42.5
Gem 0.93

Since thread loading is enabled by default, patches with multiple
pix_image created on other systems (where this issue does not exist) can
not be used without modification. If the pix_image cpu load issue is common
for Linux, the object should initialize with threadMess(0) instead of
threadMess(1) as long as the issue is not solved. I recompiled Gem with
this small change in the code and can now load arbitrary patches with
multiple pix_image. Cross-platform patch sharing would be better served by
source and binary distributions with this initialisation, until the issue
can be solved in a more satisfactory way.

Katja Vetter

----------------------------------------------------------------------

Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-05-27 22:12

Message:
I've just realised that if I send [pix_image] a "thread 0" message it stops
eating CPU.

So it is the threaded mode. Note that there's no need to actually load an
image to trigger the issue: just because threaded mode is enabled, it is
always wasting CPU.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3308535&group_id=64325



More information about the GEM-dev mailing list