On April 25, 2010 at 16:12, Lyndel McGee said...
I have been working these last few days to "scale-back" and make EscientPronto perform better such that I can utilize both TCP-based control of my Denon and EscientPronto in the same activity.
Several things have come to light that those developing modules, particularly a denon module, may find of use or want to debate/discuss.
1) More objects mean slower code operation
Whenever a callback is made to your code from the system (scheduleAfter, onSocketData, etc), the Javascript garbage collection is invoked and it does make performance a bit sluggish.
In short, the more objects you have, the more sluggish the performance. Note that functions are also objects.
After talking with Belgium, this is by design as garbage collection must be invoked. In the current "Spidermonkey", there is only a single-generation garbage collection where in the newer "TraceMonkey", there is multi-generation GC. So, if TraceMonkey were in use, things would be better but there would still be some slowdown.
2) Do you really need to monitor the most obscure messages from Denon ALL THE TIME?
All the bells and whistles are nice but...
While developing a Denon module, one has to consider all the information available from the Denon. In short, you get an event/response for lots of things that you may not be interested in. For each event/response, you must look at a minimum of 2-3 characters to see if you want to process it. This takes time and if you are interested in processing "everything", your message processor code can get very large and can be very slow. Regular expressions may help but issuing xxx.test() on 200 regular expressions to find a match on the 201st one is just plain slow. So, while we would like to process everything under the sun, it almost warrants developing several message parsers that can be invoked depending upon the things one might be interested in.
For example, having a processor for all the SS*** (System Setup) messages other than maybe SSDIM does not make sense in your normal operating code as user will not likely be in setup that much. The same goes for Surround Parameter messages (PS*). Normally, one would only be interested in maybe Surround Back settings and maybe a few more.
Just food for thought...
Comment One - More objects mean slower code operation
Makes sense, I haven't hit this tipping point ......performance is great.....I was surprised at what our prontos could do!!!!!
I delete my dynamic objects on page exit.
Questions for you.
1) Are they just marked for deletion for later garbage collection?
2) On page exit, do the dynamic objects get destroyed anyway.....in which case I don't have to clean up saving a few cycles or is it more efficient the way I'm doing it
Comment 2 - Do you really need to monitor the most obscure messages from Denon ALL THE TIME?
I personally process things that are of value......diminishing returns if you do more.
What I'm interested in are undocumented commands that will automate more daily tasks.
There are a lot of obscure things that you may want to do rarely.....my philosply is do them via the screen GUI (painful as it is)......no need to code for them.
And Gimme all the bells and whistles that I need for regular use..... :)
Bells & Whistles and good performance are not mutually exclusive.
Cheers
Dominic
