Optimisation: Should jsvIs* functions test for null pointers?

[gfwilliams]

Currently, every jsvIs* functions does a null pointer check first. How much extra space and CPU time does this use up? Can they be removed?

Initial tests using unsafe_jsvIs branch (which is by no means complete - many functions are still very unsafe) on Puck.js ...

• UNSAFE: 241644, donut.js 40.9s (38.7s minified)
• SAFE: 240948, donut.js 43.1s (41.0s minified)

So crazily the firmware size goes UP (I guess because these checker functions are often no longer inlined), but execution speed is improved by around 5%.

Maybe there's some middle ground here. Standard API functions should probably keep with 'safe' checks because it's such a vast area, so untestable and also a minimal performance win, but maybe inside the parser and jsvar.c we should start using unsafe checks?

Also worth maybe doing some benchmarking on these functions. For us to gain 5% I imagine some of them are very hot. jsvHasChildren for example is just a whole bunch of checks, and potentially a lookup table (or reordering of the enum) to allow a quick check could have a massive effect.

[gfwilliams]

We have now got defines like JSV_IS_STRING which basically do this for us, so in an ideal world we'd find out what the hot spots are (gprof?) and check if there are cases where we can safely switch from jsvIs... to JSV_IS_...