Performance concerns of C++ classes (WAS: core UGen checklist)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Performance concerns of C++ classes (WAS: core UGen checklist)

Nathan Ho
On 2018-01-02 22:17, [hidden email] wrote:
> So - looking at your reverb that you sent over (rather quickly), I’m
> wondering what kind of overhead there is to the C++ method calls on
> the classes. I usually avoid that and use Functions that pass in the
> UGen or other struct if values need to be shared / updated, and I
> wonder if that is where your performance hit is coming from.
> I’ll look more tomorrow, but that was just something I noticed tonight
> that I wanted to look more into.

hi josh,

i'm not really qualified to answer the theory of C++ performance here.
part of the reason i use modern C++ features is to learn how to use

empirically, my UGen uses about 1.3x the CPU of FreeVerb. although my
ugen has modulating and interpolated delay lines, it does seem more
costly than it should be.

i tried forcing gcc to inline every method, but i didn't see any
significant improvements. in fact i may have seen a slight degradation
in performance, but it could have been easily chalked up to statistical
noise, since my CPU measurement method is not too scientific. (running
increasingly many parallel copies of the UGens, evaluating avg CPU, and
using linear regression on the CPU percentage as a function of parallel

imo the ugen's current performance is acceptable for... uh...
performance, but i'm certainly open to experimenting with optimization.

On 2018-01-02 22:44, [hidden email] wrote:
> Originally, the plugin API was thought of being plain C without C++.
> Had we kept with this, I assume that it would have had a number of
> advantages.

fortunately that isn't really the concern here -- nothing new is
happening across the plugin API, i'm just using C++ features within an
individual plugin.


sc-dev mailing list

info (subscription, etc.):