Everytime, The First Time, and Every Bar

[mbuta]

I have a related question for which I did not find documentation.

If I have some vasriables update only "once per bar" (say MA100) do I have to declare all of them as global variable to be "seen" every tick?

Thank you.
Mihai Buta

[dloomis]

yes, it doesnt hurt to decalre variables, unles syou want the values to be 'forgetten every tick.

[mbuta]

Thank you.

I know it does not hurt, but I would like to avoid it, if posssible.
There are too many and I hate the idea, but I am having performance problems in real time and I have to do something.

So, the answer is: I have to, right?

Thanks again.

[Guest]

My experience with performance problems indicates the number of global variables has no impact on performance relative to even single instances of chart drawing and the use of debugprintln commands. Take a look at some postings by bfry5282 as he has a large number of charts open in addition to a number of EFS's. His work with the eSignal staffers and other board members to solve some very significant performance issues is interesting and very educational.

Personally, I had not had significant performance issues ... until yesterday and today where I had winsig saturation around 1:15 est. I had thought this was due to an inordinate amount of debugprintln statements catching up with me.

However, after doing some performance testing I found that system performance is not so much negatively impacted by the number of debugprintln statements, as it is by the length of the record (# of lines) in the formula output window (irrespective of the output window being open or not). Now they are related, since the more debugprintln statements there are, the longer your record will become as the day progresses...

In my test efs, one debugprintln statement took between 0.5 millisecond and 15 milliseconds per execution. As the number of lines written to and resident the formula output window increased, the execution time increased commensurate with the length. This kind of consumption is a code killer!

If you are using debugprintln in your efs's during the day, the use of the debugClear(); statement periodically in one efs to clear the formula output window can result in significant performance improvements.

Sorry I rambled so much, but hopefully this will help you or someone else with their performance issues.

Regards,

[mbuta]

If we transform this post in a performance issue, I would like to share my experience, for others to use:

1. Coloring plots and/or background creates significant overhead and slows down the system. Avoid it as much as you can.
For example, I have created a "FastView" option, so I can switch On-Off the coloring of the five Ma's and two BB. Also, I load the efs with minimal ploting (no pivots, only Ma10 and MA20). Even when I color them, I do it only for the last 300 bars.

2. Calling functions from a diferent EFS is a NO-NO.
As ugly as it is, copy them in your efs.

3. Builtin studies are much faster (I mean much faster) than any solution we may have.
Twenty bultin studies, will load faster than one "custom made".

4. Encapsulate as much as you can of your code into specific time events.
For example, at BARSTATE_ALLBARS, i initialize a bunch of variables and keep adding.
Now (that is why I started this thread) I am limiting the execution of non-time-critical parts of the code into, once per bar (BARSTATE_NEWBAR) or once per minute. A good example is the MA100, which does not need to be calculated every tick.

5. Avoid unecessary repeat "getValue(..)", like they do it with the Wizard. Create a variable (say MA10) and get its value only once per run and use the variable instead.

I hope others will share their experience and I hope that the good people at eSignal (as Brad put it) will get involved also, in between trades.