JavaScript performance VS max objects.

Wow, after easily re-writing a complex component of my patch in js, I almost don't care about the performance! Especially with being able to share function pointers via global objects, this makes things much easier to code and test.

My question still stands, though. I would love to hear about any anecdotal or empirical information on js performance in Max.

Here is a screenshot of how I imagine all max patches with complex logic look before they are ported to javascript. It looks like unreadable spaghetti...totally unmaintainable. Look familiar?

Yes it does look familiar! This is one of the reasons I started doing a lot of my logic in JS (as well as anything that requires iteration).

I too would be interested if anyone has any information on any potential performance hits we might take by doing this in JS.

P.S new to text coding - 'function pointers via global objects'. sounds fancy. care to elaborate at all?

A function pointer is a term from C programming that means you have a reference to a function that can be passed around your code, reassigned like a variable, called, etc. in scripting languages like JavaScript and Python, (unlike C) functions are objects just like everything else and are just another variable that you can assign to new names, pass to new objects, and of course call.

My reply was about how helpful it is to be able to create a Global object also assign a function to it so that other scripts can call it. This means that the max implementation of globals in JS is a bit more pure than just passing single attribute values back and forth between objects.

This really opens the door to more involved Ja programming in max because you can make callbacks without having to write a bunch of max-object level communication stuff.

I think it was mentioned somewhere that JS always runs on low priority threads.
Consequently, it should never be used for time-critical operations (?)

correct - JS runs in the low pri thread along with the UI and can get blocked by UI operations. There is also a cost of crossing the boundary into js/back from js so this also needs to be factored in.

That inplemntation make sense as JS has to be single threaded. Also great for max for live because there is typically no GUI to hog the cpu.

I assume then that midi in Live is handled in the containing track's audio thread? Then this same thread is used to enter in Max's control-rate execution graph? And then there is an asynchronous message to go from Max's audio thread to Max's own global JavaScript thread, then the same path back to Live again?

I'm just trying to sort out worse case scenario in timing so long as best case programming practices are used.

Also, what do we know about the performance of executing the JavaScript engine's byte code by itself? What overhead are we incurring just for porting application logic from pure max objects to JavaScript?

Those questions should complete the picture.

Hi !
my humble advice ... if u are going to recreate some patch logic with the code (as i do all the time) i would go for writing C external .

As if u are wondering about efficiency ? there is no question .

Javascript is very fast in Max as long as its procedures are relying on the same js document/object encapsulation . Using Global may slow it down a bit (at least ive experienced it some time ago ,and im nearly sure there was some improvements done) .

Also note that JS is processed with its interpreter engine at runtime . It means there is another layer of "computation/processing" to count in beside low priority thread issue (if thats also your concern).There is overhead but its still fast anyway .

Ive done really complex UI system that is responsive for every midi message without any real interruption . and im talking about drawing here which was my biggest concern if to touch it through JS or not . Im happy .

So for me , any "user input" stage can be threaten through JS , any "output stage" should be considered as crucial where i would pick C external writing . Which really pays off .
Here u can care for measurements or even not :)

Excellent response, thank you. I was looking for a basic feel of the responsiveness of the JS engine, it it sounds like overall it is quite positive. Especially if you were drawing at control rate which is probably the most hard core task someone can expect to do reliably with a good scripting engine implementation these days.

Most of the work I am doing is control rate anyway, as I'm not much of a DSP guy. But if things ever get crazy there will always be the c external route.

Thanks!

great ... but u have to experience it . as you were asking quite deep questions here .

it may be that u are looking for something much more responsive which u will not be able to recreate in JS ... never think of timing stuff as mentioned before , dont try to manipulate midi streams for "further max processing".
Use JS for updating your patch settings for further processing as this stuff is taking most of the space in patches .

Dont affraid of DSP . doing some data logic in C will mirror what u would do in JS but with different language habits . u dont need to do real DSP , buffer processing , interpolation or filters for that matter .really its not that crazy .
i promise .... well ok it is crazy but sometimes only :D

and if u really looking for numbers . please try to measure some things . i would love to see some numbers too .