PNS performance questions

[Dewdman42]

I have been reading the AngelScript manual. I notice that local variables are not on the stack, they are allocated on the heap every time the function is called. If needed I can work around that by allocating ahead of time some globals to use as locals. But what about function arguments? Are they also allocated on the heap?

Any other suggestions about that?

Second question, its noted that function calls are a little bit expensive because AngelScript does not do any automatic inlining. I'm coming from Javascript where the JIT inlines almost everything, making it possible to abstract a lot of stuff without performance concerns. Sounds like with AngelScript I need to be a little careful about how deep I go with function call stacks since the calls to functions are expensive? How expensive?

I don't plan to do any audio scripting (for now), but extensive MIDI processing.

any other advanced tricks people are using to avoid function call performance cost and heap allocation for locals?

Eventually I could probably move some stuff into C++ native libraries in order to optimize things more and keep the AngelScript more simple. Initially I will be prototyping everything in PNS though. I plan to creates some classes and helper functions to make it easier to work with midi sequence playback and other things, I'd prefer to have a set of Event classes in a subclass hierarchy, for example..but if the function/method call overhead is too great than maybe I won't be able to abstract as much as I would like to?

[Blue Cat Audio]

If the function arguments are passed by reference (&) or handle, they are not reallocated, no problem.

Regarding performance issues due to function calls, it may only affect functions that are called very often. Typically when called for each audio sample on the DSP side.

If you are doing MIDI, there is pretty much no overhead, unless you are processing thousands of MIDI events per second (which is definitely not likely). So you should probably not bother with that!

[Dewdman42]

Thank you! good to know. I think if I were doing anything with AUDIO DSP I would be trying to do it all within one function no question. With midi its not so much that there are thousands of midi events per second, but there could be tasks that sometimes need to traverse through hundreds or thousands of internal data structures on a per event basis in order to decide how to handle it..etc..which is potentially where the function calls could become too expensive. Maybe? Certainly I think I need to be careful about mallocing much memory when traversing through many function calls, thousands per midi event..not sure how expensive function calls are otherwise, aside from the mallocing of args and locals.

Passing by reference is good idea to avoid malloc on each call. thanks.

One question for you, I was going to create some event wrapper classes, so that I could use polymorphic approaches to handling midi events in my scripts. However, since MidiEvent is "final" I can't inherit from it, which means pretty much I would have to instantiate a new event object containing a reference to your MidiEvent...for every incoming midi event in the buffer, in order to have a higher functioning wrapper event object than what MidiEvent is now, with more methods, ability to execute methods polymorphically, etc..

I'm trying to decide whether that would become too expensive. Maybe not. that would be one object malloc per midi event...which as you said..is not nearly as intense as audio DSP. a few per second. All the mallocing will eventually cause garbage collection though. So still I'd rather avoid that maybe. If its truly non-issue for midi I won't worry about it I'll just create a new wrapper object for every midi event in the buffer. If you think the perf might be significant, I'll have to either avoid the polymorphism stuff I want to do...or some kind of crazy proxy class thing that will pre-allocate a bunch of these new event class objects in order to assign MidiEvent references to as the midi comes in, but that seems way overly complex.

Or any other suggestion you may have about extending MidiEvent in angel script, would be welcome..

[Blue Cat Audio]

Polymorphism won't be the issue here. Allocating new objects during the "process" call though is not a good idea (even in C++).

Before going into complex polymorphism, you may want to keep it as simple as possible anyway. Especially with MIDI events there is not much you can actually do using inheritance. You will end up checking event types anyway at some point.

[Dewdman42]

I know angel script supports polymorphism..that's why I was hoping to use it. Unfortunately I can't inherit from MidiEvent. Since I can't inherit from it and cast to it, then the only way would be through containment, which in the simple case would involve allocating a new object in processblock. Thanks for confirming my suspicion that this would not be a good idea.

There might be some other tricky ways with proxy classes, but I'll play around with that later I guess.. Probably more hassle then its worth perhaps.

sorry for this low level anal thought process right now, I just want to think through the implications before I start developing my scripting helper functions I plan to use to implement higher level stuff. I have a few things I did in LogicPro Scripter that I intend to translate over, and some of them are fairly complex with deep structures needed.. This could mean function stacks 5-6 levels deep... hopefully if I pass by reference and don't use any locals...that will not hit the heap too much.

[Blue Cat Audio]

Unless you are processing thousands of events per second you should be safe. MIDI is usually pretty lightweight in terms of data rate!

Inheriting from MidiEvent would not help anyway, as the events that you have to process are coming from the host and hence would not be available as your derived class.

[Dewdman42]

well anyway its not worth the trouble of figuring out. True..I had not thought about getting the data back to the buffer...

Well I will just try first by creating a new object for each one and see how it performs. As you said, might not be a problem for midi.

But. I will make sure all function calls are passing things by reference and no locals. thanks for that tip.