Your Universal Remote Control Center
RemoteCentral.com
Philips Pronto Professional Forum - View Post
Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Original thread:
Post 30 made on Sunday April 25, 2010 at 16:12
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
13,007
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...
Lyndel McGee
Philips Pronto Addict/Beta Tester


Hosting Services by ipHouse