[PD] Re: reduce CPU usage

guenter geiger geiger at xdv.org
Mon Jun 23 14:30:23 CEST 2003


On Sun, 22 Jun 2003, tigital wrote:
> On Sunday, June 22, 2003, at 03:55  PM, tigital wrote:
>
> > On Sunday, June 22, 2003, at 07:19  AM, Shintaro Miyazaki wrote:
> >>
> >> download it at . www.gezetera.ch/noise/supercpu.pd
> >>
> >> thank you in advance.
> >
> > hello miyazaki,
> >
> > ...very nice looking patch, but that is the problem
> > (unfortunately)...all that use of color is pretty, but horribly
> > un-optimized, at least on the mac tcl/tk side...this is an incredible
> > limitation to the usage of pd in any but an "experimental" manner...I
> > have been working on moving tcl/tk's graphics to native coregraphics
> > calls, but it is a big project, and I'm not convinced that it wouldn't
> > be better to rewrite the pd gui in something else...but it's also
> > apparent that the problem is not just the OSX tcl/tk, because I also
> > get about 56% pd cpu usage with the patch sitting idle, and tcl/tk is
> > barely 5-10%...it's disappointing that pd spends so much time with
> > inefficient drawing calls...
>
> ...just as a bit of followup, I looked at the idle patch open via
> shikari, and here's how the function usage is breaking down for pd &
> zexy:
>
> 	17.8%	sighip_perform	pd
> 	11.7%	tabread4_tilde_perform	pd
> 	9.7%	siglop_perform	pd
> 	6.8%	plus_perf8	pd
> 	5.3%	scalartimes_perf8	pd
> 	3.5%	times_perf8	pd
> 	2.3%	osc_perform	pd
> 	2.2%	line_perform	pd
> 	1.8%	sigvd_perform	pd
> 	1.3%	cos_perform	pd
> 	1.3%	tabosc4_tilde_perform	pd
> 	1.0%	sig_perf8	pd
> 	0.9%	phasor_perform	pd
> 	0.7%	dsp_tick	pd
> 	0.5%	sigwrap_perform	pd
> 	0.4%	pa_send_dacs	pd
> 	0.3%	noise_perform	pd
> 	0.2%	plus_perform	pd
> 	0.2%	sigbp_perform	pd
> 	0.2%	copy_perf8	pd
> 	0.1%	sys_getrealtime	pd
> 	0.1%	tabwrite_tilde_perform	pd
> 	0.1%	m_scheduler	pd
> 	0.1%	sys_addhist	pd
> 	0.1%	scalarplus_perf8	pd
> 	0.1%	readsf_perform	pd
> 	0.1%	sigdelwrite_perform	pd
> 	0.1%	RingBuffer_GetReadRegions	pd
> 	0.0%	PaOSX_HandleInputOutput	pd
> 	0.0%	ReadAudioStream	pd
> 	0.0%	restFP	pd
> 	0.0%	sys_pollmidiinqueue	pd
> 	0.0%	scalarminus_perf8	pd
> 	0.0%	sig_perform	pd
> 	0.0%	sys_domicrosleep	pd
> 	0.0%	sys_poll_midi	pd
> 	0.0%	sys_pollmidioutqueue	pd
> 	0.0%	RingBuffer_Write	pd
> 	0.0%	Pa_EndUsageCalculation	pd
> 	0.0%	Pa_StartUsageCalculation	pd
> 	0.0%	RingBuffer_GetWriteRegions	pd
> 	12.5%	z_index_setup	zexy.pd_darwin
> 	3.9%	z_sigbin_setup	zexy.pd_darwin
> 	1.3%	z_noise_setup	zexy.pd_darwin
> 	1.0%	z_pdf_setup	zexy.pd_darwin
> 	0.1%	zexy_setup	zexy.pd_darwin
>
> ...so, we'd need to findout what all the zexy setup functions are for,
> not to mention those pd *_perform functions...

Seems that there is something wrong with the profiling, because all
of these setup functions are only called once, and therefore should
not contribute anything.

OTOH it is normal that the perform functions use the bigger part of
the CPU, because this is where the work is done.

Depending on how many of these hip~, lop~ and tabread4~ objects are in
the patch (I can't access it to check myself), there might be a problem
with the optimization of this code on PowerPC's.

Well, some one would have to check these and take a look why the Mac
compiler has problems there.

Guenter


>
> ...wish shell, on the other hand, isn't really doing anything once the
> patch is open, but that would change if any gui stuff changes...
>
> l8r,
> jamie
>
>
> _______________________________________________
> PD-list mailing list
> PD-list at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>





More information about the Pd-list mailing list