why does this happen?

[clearpicks]

Jason,

Thank you very much. I am looking forward to your testing results. If the findings in my posts can be confirmed by your results, it would improve the performance of eSignal 10 greatly in certain cases.


-Clearpicks

[eSignal_JasonK]

Hello Clearpicks,

First, thank you for taking the time to provide your findings and test scripts.

Based on the testing I've done so far, I do see similar results in terms of the dms values that you've described. However, I'm also seeing the behavior in 8.0 (build 782). The frequency at which the problem occurs is much lower and the overall dms number is much lower as well. The max value I've seen so far from 8.0 is 10 ms.



This isn't a bug that is specifically introduced in 10.0 as the behavior exists prior to that build. At this time I cannot say that it is a bug that is specific to EFS or the sym()/inv() implementation. I will certainly pass the scripts along to our developers for closer investigation.

We do know and have acknowledged that the 10.0 series is less efficient than 8.0 in overall. The larger dms values produced in the 10 series may not be caused by the EFS2 engine but other areas of the application. Identifying the specific areas causing this difference in performance is a complex task and equally complex to resolve. The test scripts that you created may be one additional method for us to analyze the performance of the applications between builds. Improving the overall performance has been one of the primary objectives for the 10.1 version. Our development group has already been profiling the performance of the 10 series with 8.0 as part of the process for making improvements for the 10.1 version. This process will continue beyond 10.1 as well.

[clearpicks]

Hello Jason,

Thank you for your response.

If you remove all sym() and inv() in the test script and replace with something like getValueAbsolute(...., "UNG,1") etc. and you would not see non-zero dms being printed out. That is the reason I thought it was introduced by sym() and inv(). Due to the relative large value of dms in esignal 10 compared to 8, the loading time of my layout page is also much slower than that in esignal 8. It seems sometimes such CPU usage spike duing startup may cause the incorrect last daily bar being built. I asked a question about how esignal builds the last daily bar on charts but got no complete answer. I suspect these two threads are closely related.

http://forum.esignalcentral.com/show...threadid=26331


- Clearpicks

[eSignal_JasonK]

Hello Clearpicks,

Originally posted by clearpicks
Hello Jason,

Thank you for your response.

If you remove all sym() and inv() in the test script and replace with something like getValueAbsolute(...., "UNG,1") etc. and you would not see non-zero dms being printed out. That is the reason I thought it was introduced by sym() and inv().

The EFS2 sym/inv synchronization requires more work by the application because the process synchronizes by time tamp. The EFS1 methodology of getValueAbsolute(...., "UNG,1") does not do proper symbol/interval synchronization. It simply makes reference to the other symbol or interval based on the bar index that is relative to the chart being processed. This results in improper symbol/interval synchronization when the other chart symbol does not have the exact time stamp for each bar index. This can happen for two symbols that do not have the same trading session or zero volume bars. EFS1 calls do not do any syncing for external intervals. The getValueAbsolute() call does not perform the same level of work required to properly sync external symbol data, which is why it executes in less that 1 millisecond.

]Due to the relative large value of dms in esignal 10 compared to 8, the loading time of my layout page is also much slower than that in esignal 8.

This is a known problem and work has been done to improve this in the 10.1 beta.

It seems sometimes such CPU usage spike duing startup may cause the incorrect last daily bar being built. I asked a question about how esignal builds the last daily bar on charts but got no complete answer. I suspect these two threads are closely related.

This is not related to EFS. Please see this thread regarding your daily bar question.

[clearpicks]

Jason,

I understand the extra work involved in sym() and inv(). Actually even before the release of EFS2, I wrote my own multi-symbol multi-interval scripts in which serieses of different symbols/intervals are also aligned as sym() and inv(), and it ran much faster than currently using sym() and inv(). I mentioned replacing sym() with getValue() in test script just to prove that it is sym()/inv() causing the extra processing time. It just does not make sense to take several hundred miliseconds to align serieses of two symbols given the modern CPU processing power, so it is purely an implementation issue caused by wrong data structure or algorithm.


- Clearpicks

Originally posted by JasonK
Hello Clearpicks,



The EFS2 sym/inv synchronization requires more work by the application because the process synchronizes by time tamp. The EFS1 methodology of getValueAbsolute(...., "UNG,1") does not do proper symbol/interval synchronization. It simply makes reference to the other symbol or interval based on the bar index that is relative to the chart being processed. This results in improper symbol/interval synchronization when the other chart symbol does not have the exact time stamp for each bar index. This can happen for two symbols that do not have the same trading session or zero volume bars. EFS1 calls do not do any syncing for external intervals. The getValueAbsolute() call does not perform the same level of work required to properly sync external symbol data, which is why it executes in less that 1 millisecond.



This is a known problem and work has been done to improve this in the 10.1 beta.



This is not related to EFS. Please see this thread regarding your daily bar question.

[clearpicks]

It seems this bug has been fixed in eSignal 10.1 build 1231. Jason, could you confirm this? Thanks.

- Clearpicks

[eSignal_JasonK]

Hello Clearpicks,

Yes, it was fixed. Thank you for checking it and thanks again for bringing this to our attention.