Gem sucking whole CPU for no visible reason... intermitently WAS Re: [GEM-dev] Re: [PD-dev] oprofile - streamlining Pd/gem patch

[chris clepper]

I think you need a better profiler which traces the calls.  Just listing the
libs is only marginally more useful than top.  There's nothing to indicate
if the driver is spending time uploading textures or vertices or just
waiting for the GPU or doing something stupid. Without that info there is
little anyone can do to fix any problems.

On 5/16/06, B. Bogart <ben at ekran.org> wrote:
>
> Hey all,
>
> So I'm going to leave the patch on overnight and *HOPE* that it does not
> due the weird spike while I'm gone.
>
> Right now this is what the profile looks like:
>
>           5028091 51.5756 libGLcore.so.1.0.8756
>           2287523 23.4643 Gem.pd_linux
>           1155076 11.8482 zero
>            402984  4.1336 pd
>            336232  3.4489 libfreetype.so.6.3.5
>            210094  2.1550 libc-2.3.6.so
>            179207  1.8382 libm-2.3.6.so
>             75334  0.7727 libGL.so.1.0.8756
>             63900  0.6555 libX11.so.6.2
>              4586  0.0470 libpthread-2.3.6.so
>              3691  0.0379 libGLU.so.1.3
>              1618  0.0166 comport.pd_linux
>               199  0.0020 expr.pd_linux
>               182  0.0019 libpython2.3.so.1.0
>                78 8.0e-04 zexy.pd_linux
>                72 7.4e-04 libstdc++.so.6.0.8
>                46 4.7e-04 py.pd_linux
>                30 3.1e-04 xsample.pd_linux
>                17 1.7e-04 pool.pd_linux
>                11 1.1e-04 prepend.pd_linux
>
> So the question is, what the heck is "zero" and why is pd linked with
> it???
>
> I really hope this newer binary fixes the issue.
>
> Thanks all for your help.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20060516/a8bcdaac/attachment.htm>