Howdy, Stranger!
We are about to switch to a new forum software. Until then we have removed the registration on this forum.
Categories
- All Categories 25.7K
- Announcements & Guidelines 13
- Common Questions 30
- Using Processing 22.1K
- Programming Questions 12.2K
- Questions about Code 6.4K
- How To... 4.2K
- Hello Processing 72
- GLSL / Shaders 292
- Library Questions 4K
- Hardware, Integration & Other Languages 2.7K
- Kinect 668
- Arduino 1K
- Raspberry PI 188
- Questions about Modes 2K
- Android Mode 1.3K
- JavaScript Mode 413
- Python Mode 205
- Questions about Tools 100
- Espanol 5
- Developing Processing 548
- Create & Announce Libraries 211
- Create & Announce Modes 19
- Create & Announce Tools 29
- Summer of Code 2018 93
- Rails Girls Summer of Code 2017 3
- Summer of Code 2017 49
- Summer of Code 2016 4
- Summer of Code 2015 40
- Summer of Code 2014 22
- p5.js 1.6K
- p5.js Programming Questions 947
- p5.js Library Questions 315
- p5.js Development Questions 31
- General 1.4K
- Events & Opportunities 288
- General Discussion 365
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...