Closed ebaauw closed 9 months ago
Looks fine but I wouldn't include the eslint comments.
I would, obviously, but removed the comment.
I would hope the JS is parsed and compiled only once? Or is it compiled at every invocation (in which case, we might want to remove white space, comments, use short variable names, etc)?
Thanks, imho such things better go into a $EDITOR /eslint user.preferences or we provide a global one.
I would hope the JS is parsed and compiled only once? Or is it compiled at every invocation (in which case, we might want to remove white space, comments, use short variable names, etc)?
Right now it is actually parsed, compiled and executed on each invocation. I've looked into DuktapeJS docs and it is indeed possible to safe/reload the generated bytecode which would safe the repeated parsing and compile steps (still much slower than a V8 engine JIT, but safes a few cycles). I'm planning to test this out more but first some other refactoring needs to be done to cut more drastic bottle necks.
You can get a feeling on the performance by enabling MEASURE and JS debug logging. Even with the non optimized approach it's surprisingly fast on average and mostly uses less than 250 KB on RAM in total. We currently have a lot of other more heavier performance hogs in the C++ side of the code base.
But as said earlier for me JS should be kept to a minimum and really boring noob safe code :)
The main purpose is to do things like Item.val = Attr.val * 10
. It's not always possible but 95% of our JS code should be like this and not much more complex, until a better solution is found for the remaining 5%.
From my point of view the more complex JS scripts we have are only temporary to figure out generic ways later on to tackle the tasks they do in a declarative way.
Fixes parsing the State attribute of the Hue Effects cluster, see #7551
on
,bri
, andct
;on
, also for unsupported modes.(Dunno why it lists all these commits, but only one changed file).