On Tue, Dec 11, 2012 at 8:58 PM, Hans-Christoph Steiner wrote:
> I added optimization flags to the GNU/Linux and Windows builds:
>
> http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revision=16655
> http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revision=16
On Dec 10, 2012, at 9:40 AM, katja wrote:
> On Fri, Dec 7, 2012 at 11:46 PM, Hans-Christoph Steiner wrote:
>>
>>
>> Thanks for this write-up and all that testing, its definitely very
>> helpful. So in the end, you're talking about Pd-extended on debian only?
>> It sounds like your tests show
On Fri, Dec 7, 2012 at 11:46 PM, Hans-Christoph Steiner wrote:
>
>
> Thanks for this write-up and all that testing, its definitely very
> helpful. So in the end, you're talking about Pd-extended on debian only?
> It sounds like your tests show that 0.43 was not slower on Mac OS X.
>
> It does loo
Thanks for this write-up and all that testing, its definitely very helpful. So
in the end, you're talking about Pd-extended on debian only? It sounds like
your tests show that 0.43 was not slower on Mac OS X.
It does look like the Debian-i386 builds don't have optimization turned on, you
can
Finally I have some clue what's wrong with Pd-E 0.43 for GNU/Linux, or
for Debian Squeeze at least. Sorry that it took me so long to sit down
and sort it out.
The problem is still there, with version 0.43.4: my live performance
setups run with almost double CPU load, when compared to 0.42. Now I
a
Hi Katja,
On 5 May 2012, at 20:43, katja wrote:
>
>
> I've tried to use Oprofile on Debian, but this gives me a kernel
> failure soon as I start sampling. Does anyone know of a fine
> performance profiler for GNU/Linux?
>
> Katja
>
>
You might want to try callgrind + kcachegrind...
http
Hmm, interesting idea. Katja, do you have the CPU meters on?
.hc
On May 5, 2012, at 4:57 PM, Ivica Ico Bukvic wrote:
> Could it be the VU meters embedded in the main window? Those are known to be
> fairly cpu intensive if updated too often.
>
>
>
Could it be the VU meters embedded in the main window? Those are known to be
fairly cpu intensive if updated too often.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
On 05/05/2012 03:58 PM, Jonathan Wilkes wrote:
Have you compared with pd-l2ork in Debian? Without doing any direct
measurements, I seem to remember the pd-0.43-ext nightly build looking
sluggish on my laptop when moving around GUI objects, which I didn't
see with pd-l2ork. -Jonathan
That is be
- Original Message -
> From: katja
> To: pd-list
> Cc:
> Sent: Saturday, May 5, 2012 3:43 PM
> Subject: Re: [PD] what makes Pd-extended 0.43 so CPU-hungry?
>
> On OSX I use 'Activity Monitor' for quick check of CPU load and
> Shark.app for serious
On OSX I use 'Activity Monitor' for quick check of CPU load and
Shark.app for serious performance profiling, but for GNU/Linux I don't
know a good equivalent of Shark. So on Debian I just start top, and
for my live performance setup which does ~40% CPU load with
Pd-extended 0.42, it is ~60% with 0.
I honestly don't know the cause, and haven't really checked on numbers. I
mostly work on my four year old laptop, and test by running patches I know
(solitude is a good test of heavy CPU usage, it won't run on a machine less
than 1.6GHz, from my experience).
As for drawing operations like ant
Hello,
I've installed Pd-extended 0.43 versions (Linux and OSX) from the
autobuilds several times in the past year. The latest builds seem to
work fine in many aspects, but they are still so CPU-hungry: ~ 50%
more than Pd-extended 0.42. How come?
A while ago, the new PortAudio version was blamed
13 matches
Mail list logo
