weird behavior of EFS

[clearpicks]

I found the following weird thing while debuging my EFS. If I apply the following EFS to "$SPX,5", it can be seen that main() is ccaled roughtly every 6 seconds ( the interval of $SPX update time ).
/***************************************/
var q = 1;

function preMain()
{
setPriceStudy(true);
}


function main() {

debugPrintln(q);
q = q + 1;

}
/****************************************/


However if I added two lines in it, and run it again, the main() is called in much much higher frequency. I guess whenever the volume of QQQ and SPY change, this EFS is notified and main() is called once, which is way wrong and deteriorate the performance. I guess quite a lot of eSignal user are not aware of this. Any comments?

/***************************************/
var q = 1;

function preMain()
{
setPriceStudy(true);
}


function main() {

debugPrintln(q);
q = q + 1;

var c = volume(0, -22, "SPY,5");
var d = volume(0, -22, "QQQ,5");

}
/****************************************/



-- Clearpicks

[clearpicks]

I found out this kind of unwanted main() calling exists whenever the price of other symbols is accessed through APIs like close(), getValue() etc. I suspect this is the reason that eSignal limits the maximal number of symbols one EFS can access to 5 because otherwise the frequency of calling of main() shall increase dramatically. However this design is flawed. main() should be called only when new data of the symbol, to which the EFS is applied, arrive. Please comments on this and provide some kind of solution. I believe many eSignal users are experiencing unnecessary performance degration due to unwareness of this problem.


-- Clearpicks

[eSignal_JasonK]

Hello Clearpicks,

You are correct in your observation of how main() is executed and it is part of the reason why we have a symbol limit of 5. However, I'm not sure we can say it's a flaw. It really depends on what the formula in question is supposed to do. If a real time formula uses a combination of prices of different symbols and the user wants a particular calculation to reflect the current price of all symbols in question, an execution of main() would be required if one of the external symbols changed while the chart symbol was static. I can see how this behavior could be problematic to certain scenarios, but I think the more common routines would require the execution of main on any change event. Would the setComputeOnClose() option help you in this case? Tell me more about what you are trying to accomplish. Perhaps we have a case for a new EFS option.

[clearpicks]

Thanks for your prompt reply. Why not add one more option such as setComputeOnPrimarySymbolOnly so that the user can sepcify his preference in premain(). Another problem I found out is that there is no way to find out which symbol's data tragering the execution of main() in my test scenario. Therefore I have to either do quite a few tricks to find it out or unnacessarily calculate and update the indicator. Either way is wasting my CPU time.
I believe most EFS users don't expect this (main() being called due to new data from none-primary symbols) because it contradicts to intuitiveness and also is not clearly documented in the manual and online help.

-- Clearpicks

Originally posted by JasonK
Hello Clearpicks,

You are correct in your observation of how main() is executed and it is part of the reason why we have a symbol limit of 5. However, I'm not sure we can say it's a flaw. It really depends on what the formula in question is supposed to do. If a real time formula uses a combination of prices of different symbols and the user wants a particular calculation to reflect the current price of all symbols in question, an execution of main() would be required if one of the external symbols changed while the chart symbol was static. I can see how this behavior could be problematic to certain scenarios, but I think the more common routines would require the execution of main on any change event. Would the setComputeOnClose() option help you in this case? Tell me more about what you are trying to accomplish. Perhaps we have a case for a new EFS option.

[clearpicks]

I'd like to advocate once again to remove the symbom limit because I really see no reason to set this limit. It is the user's responsibility to control time consumption of those EFS. Right now I have to use many auxiliary EFS' to process extra symbols and communicate with my primary EFS throught setGlobalValue and getGlobalValue. Thanks god, due to my persistence, a bug in getGlobalValue() and setGlobalValue() was acknowledged and fixed since ver. 7.2, which reduced the overhead of setGlobalValue() from tens milliseconds to less than a few milliseconds, thus my trick works. However it is really ugly to see my whole program has to be devided into a lot of EFS' and a lot of threads and quite a lot unnecessary overhead is introduced by this unreasonable symbol limit. Please reconsider this symbol limit issue if possible.


Regards,
Clearpicks

[eSignal_JasonK]

Hello Clearpicks,

Please submit your suggestion for the setComputeOnPrimarySymbolOnly() and the related details to [email protected], our development reviews this mailbox. I will add the suggestion to my list as well. You may also plead your case for the symbol limit at that address, but the best place might be the eSignal 7.x forum. The main reason for the symbol limit is to prevent excessive server abuse from a single EFS formula. If we didn't have a limit, everyone would be developing scanners, which would create problems for us on the server side. That is as much as I can contribute to the symbol limit issue.

You may want to take a look at our new ActiveX API