Optimization Report

[sephult]

So working on a pretty complex patch I was thinking:

It would be good to have a report on which objects consume the most CPU.
I would love to see an optimization report that could inform what kind of trade-offs you could make in a design.

Like opting for using range faders instead of another XY and array for logic.
Now knowing and process of elimination I realize I have 16% that I would like to cut back on...but where.

I think this idea of having a report with object/id and the cpu usage would be priceless.

-S

[senso]

For many reason a complete diagnostic of a PATCH consumption is not easy.
- modules take CPU
- wire also, and moreover it' depends on what you send in.
- all graphic stuffs (colors, positions, etc) and IML commands are calculated in parallel threads with low priorities.

For example a patch can have a low CPU consumption in the audio thread but saturate the graphic thread and so unable to work properly.

For me the solution is to create a document like "what are good patching rules" ?

[sephult]

Hi Senso,

Actually that is the idea I am trying to lead to as well with a patching and design documentation to help with.
I'd like to try to understand more about the "tax" of items for efficiency.
I think it would be very beneficial to document standard module CPU consumption, behaviours etc...

One thing I have learned is that a delay module seems to consume more CPU, when idle....then when fed an audio source it reduces CPU (I assume a threading function comes in). These kind of relationships I'd like to understand more and document for others as well.

Moreso, not necessarily a 100% detailed output from HH programmatically, but more of an understanding of how many Objects are used, and more understanding for optimizing complex patches to make them more compatible on multiple setups.

I can create a utility to parse the .pat file and give details about how many objects, what types, etc.... I will work on this, along with a patching design and rules.

Here is a question and idea though:

So one of the questions regarding "measuring and understanding CPU usage"..... If three types of CPU items are really in use....wouldn't it be beneficial to separate the CPU usage of these into their own Meter along with the combined output.

Say a Graphic CPU use meter, an Audio CPU use meter, and Object/Application use one....then the combined CPU output?

By having these available If someone has issues, I can understand quickly and easily to say "Your graphics card is not able to handle", maybe you should update it. Or possibly your audio driver, bloc, or buffers are not high enough. It would give a higher understanding of how the patch is working even on multiple setups, and understanding this over-time would lead to efficiency in designing user patches.

Would if be difficult to put CPU meters on the individual thread priorities? Maybe even under the debug options?

-S

[senso]

In usine we use a complex messages system to delegate calculation from one thread to another.
So, messages queues can handle messages from any patch and it's hard to evaluate the CPU consumption of a particular one.

The messages queue are:
1) graphic, to repaint all objects
2) idle, to execute all non graphic and low priority: ie loading samples of a sampler, in fact most of non audio things.
3) very low priority message likes file/open workspace.

[r.erorr]

"good patching rules" could be as separate forum for general patching strategies like "how to do this or that more efficient? how to simplify? some elegant way for . . . ? etc"

I remember how I thought few years before, it's completely different right now.

[sephult]

I agree with you r.error
Design styles and methods just seem to keep changing. Would be wonderful if we could break that curve and all share our methods.
Quite possibly we could build better and more efficient tools to share.

-S