The Need For Speed

[buzzhorton]

I am pushing the limits of eSignal EFS with my TRO SLOT MACHINE studies.

I don't know all the tricks and traps of eSignal EFS yet.

Can someone please tell me the "shoulds" and "shouldn'ts" when it comes to coding for speed.

For example:

Is it better to embed functions or not imbed functions?

Are arrays a drag on the system?

Should eval be avoided or embraced?

Etc...

I realize there are tradeoffs.

But since I don't know the answers, I don't know what the tradeoffs really are.

Thanking You In Advance.

[arbor03]

I would be interested in the answers to the below questions as well.

[gspiker]

I don't know if you will get any detailed answered, but some of this has been discussed before on an individual basis (ie: which is better x or y) or on a discovery basis (ie: I just ran a test on externalEFS and did you know it was xx% slower than calling an internally defined function?).

I bet if you do a search on "EFS performance" on the BB you will find these, and also find some posting on how best to determine what is taking up most of your system resources for your specific EFS formula’s.

Here are some things I remember:

1) If you don't need lines/images/graphics updated each tick, then put checks in for NEWBAR before rendering

2) Keep lines/images/graphics to a minimum (I use buttons in some of my EFS's to be able to toggle on and off what I am displaying)

3) Use built-in functions when possible. They are run natively and are much faster to execute than a similar EFS function

4) Calling external EFS formula's has a performance penalty. This ends up being a reuse vs. performance issue

5) If there are sections of your code that you know are very CPU intensive, think about how you may be able to run it less often. Sometimes you can do this, sometimes not.

6) Printing to the formula output window is a huge penalty. If you have debug code going to the window get rid of it. Output to a file instead if you really need the information.

7) Some functions (like the date functions) take an unseemly amount of time. Don't use them if you don't need to.

That's all I remember off the top of my head. Like I said, I would look at old articles that talk in detail about how to determine what functions are taking up the CPU and you should be able to narrow down the issues.

Garth

[buhrmaster]

First if you do a google search for 'javascript speed' or something like that you can get a number of responses. One thing is that different javascript engines have different results.

In general the things that cause the worst performance are graphics, including writing to debug (so watch for forgotten debugPrint statements), and variable declaration (memory allocation) but this is true of any language. My guess is that arrays are not an issue once their memory is allocated. From then on the stack just has to keep track of the array pointer I would guess and assignment is fast. In general the use of var as a type slows a system down. I don't know if javascript supports more explicit types but if so it is better to use them. Objects are like arrays -- memory is allocated, the system hangs on to a pointer. Keep declarations out of loops, obviously.

I would be curious if offloading computation to a dll would increase performance. On the one hand there is the function lookup but on other you may get several thousand times faster computation. I once took VB code (scripting environment similar to javascript) and compiled it to a dll and got 6X better performance when running it as an add-in to excel.

Just a few ideas off the top of my head.

[buzzhorton]

Thanks for the tips and hints.