P5 vs Native JS methods

This post stems from this thread; but I think it warrants a separate post here...

@GoToLoop: It had of course crossed my mind that the reason for creating wrappers to native JS functions was to provide a consistent syntax and be consistent with the Processing language ;)

I was just wondering whether this approach is as appropriate with an interpreted (as opposed to pre-compiled) language; particularly when working with potentially resource intensive applications. I don't really know enough about Java compilation; but I'd assume that it will optimise in the case of a function call that is simply wrapping another function...

In JavaScript every function call comes with a performance cost. Obviously it is pretty minimal; but it could possibly have an impact; especially with functions that are called very frequently on lots of objects. So the fact that p5.split() and p5.splitTokens() both essentially call JavaScript.split() (which will accept a regex as a parameter) probably isn't a big deal; but what about the Math methods? Exposing these to the global scope so people can write atan2(y, x) instead of Math.atan2(y,x) feels a little redundant; particularly if it does come with a performance hit; however minimal...

This is of course not meant as a criticism. I'm just curious as I suspect this discussion may already have taken place...

Sign In or Register to comment.