Gem sucking whole CPU for no visible reason... intermitently WAS Re: [GEM-dev] Re: [PD-dev] oprofile - streamlining Pd/gem patch
ben at ekran.org
Tue May 16 18:13:09 CEST 2006
we'll I've narrowed down the issue to lots of pix_buffer writing, but I
can't be sure without getting the profiling to work. No matter what I do
oprofile just shows me pd symbols, not the gem ones.
Anyhow the patch very simply moves the camera to look at different things
in the room, if the pix_motion -> pix_blob analysis it decides if the
frame is worth capturing. Then it gets added to a pix_buffer.
It cycles through 50 buffers each with 3 slots.
The CPU usage stays around 25% most of the time, going up to maybe 35%.
Then once and a while (and more and more and longer and longer while the
patch is running) it jumps up to 100%. Eventually the patch seems to stay
at 100%. even if I stop the cycling, and therefore stop the capturing, the
motion analsys and everything, all that is left is the video capture (v4l2
on winTV 640x480, usually uses 5-8%), and the CPU usage stays 100%. I've
now left it for about 20min after stopping the cycle and the CPU usage is
Could someone please help me profile this thing so I can at least find the
I'm going to get something to eat now, so I'll be back on #dataflow in an
On Tue, May 16, 2006 9:27 am, IOhannes m zmoelnig said:
> B. Bogart wrote:
>> Hi Johannes,
>> When I do: autoconf && ./configure && vi Make.config
>> I only see the following lines containing "[sS][tT][rR][iI][pP]":
>> STRIP_UNNEEDED ?= --strip-unneeded
>> STRIP ?= strip
>> So I'll comment those out and see what happens.
> uncommenting is a not-so-good idea.
> ~> STRIP=echo make
> without(!) editing the Make.config
> (or alternatively change the line "STRIP ?= strip" to "STRIP ?= echo" --
> actually that is what i meant by "replacing the STRIP-command with
More information about the GEM-dev