Re: Max-specific C code optimization guidelines ?

Hello,

A/ Remarks :

- IMHO it is not a good idea to break encapsulation rules with code like that :
x->input_list2[i].a_w.w_float ; the CPU gain is not significant and your code may be broken by futur API release.
- i do not know if flop_new(long n) is “old style class” but flop_new(t_symbol *s, long argc, t_atom *argv) is more usual.
- i’m not used with proxy ; but according to (thanks Jamoma team) https://github.com/jamoma/JamomaModular/blob/master/implementations/MaxMSP/jcom.gang/jcom.gang.cpp your code looks bad.

B/ CPU !

I implement a [flop] test external only with your list processing part to make tests and AFAIK your external seems very light ; 8% may be the result of [multislider] paint method (in main thread).

# Report 0 - Session 1 - Time Profile of MaxMSP
SharkProfileViewer
# Generated from the visible portion of the outline view

...

- 0.0% semaphore_wait (libSystem.B.dylib)
- 0.0% semaphore_timedwait_signal (libSystem.B.dylib)
- 0.0% pthread_get_stacksize_np (libSystem.B.dylib)
- 0.0% dyld_stub__spin_unlock (libSystem.B.dylib)
- 0.1% GetKeys (HIToolbox)

- 0.1% flop_list (flop) // ###

- 0.1% CGSScoreboard (CoreGraphics)
- 0.1% CGSGetKeys (CoreGraphics)
- 0.2% CAHostTimeBase::ConvertToNanos(unsigned long long) (CoreAudio)

...

and even focused on your external :

# Report 1 - Session 1 - Time Profile of MaxMSP
SharkProfileViewer
# Generated from the visible portion of the outline view
+ 100.0% flop_list (flop)
| - 75.0% outlet_list (MaxAPI)
| - 8.9% atom_setfloat (MaxMSP)
|   3.6% proxy_getinlet (MaxAPI)
|   3.6% atom_getfloat (MaxAPI)
|   1.8% atom_gettype (MaxAPI)

you can see that most part is used by [multislider] connected to the outlet.

My 2 cents : you can make your external more readable using an array of t_atomarrays pointer in your structure that you can allocate dynamically in your new method ; but i don’t thing you can really improved the efficiency with tricks …

Attachments:
  1. bottleneck.zip
Jul 27, 2012 at 8:26am #229889