eSignal CPU usage

[clearpicks]

No, not yet.

[sandpiper]

Clearpicks,

I've just tried my set of tests on 10.5.1643 and the issue appears to be fixed.

It would be nice to have an idea from the guys roughly where the issue actually was, in terms of functionality.

Regards,

[sandpiper]

Looks like I spoke too soon I'm afraid..

Initial tests showed that CPU usage on charts was negligable when the underlying market is closed. However, when the underlying market is open, there is a marked increase in CPU usage related to the size of the advanced charting window being used.

On my test set-up with 4 x normal aspect 19" screen with a resolution of 2560x2048, an undocked chart of an active, but certainly not frantic market @ approx 1 tick per second, reaches a steady CPU usage of between 36% and 40% (2.4gig processor). The amount of data displayed (various time templates used) makes no difference to this figure.

The same 2560x2048 chart when used on a closed market uses 0% CPU.

When the chart size is reduced to 1280x2048 the CPU usage is steady at 11% for an open market and 0% for a closed market.

When the chart size is reduced still further to 1280x1024 the CPU usage is 7% for an open market and 0% for a closed market.


The CPU usage has nothing to do with any user modifiable parameter such as scaling. I have tried switching them all to different settings to no avail.

All of this compares with near neglible CPU usage on 10.1 when charting the same open market.

Regards.

I'm going back to 10.1 and staying there. I may even re-assess the need for moving to 10 at all and regress to an even earlier version.

Regards.

[clearpicks]

By comparing the CPU usage in 10.1 and higher version, it is obvious that a bug was introduced since eSignal 10.2 cuasing this abnormal CPU usage issue. One month has passed since I reported this issue. Can someone from eSignal confirm that this bug is under investigation and going to be fixed in future release? Thanks.


- Clearpicks

[jgr]

I did read in the 10.5 Beta stuff, I believe, that they had improved the threading in the code to help with the CPU load issue.

Drawing on my own background in software/firmware, I suspect the issue may be hard for them to tackle without some substantial rework in the architecture of the system. This for my assumed reasons:

1. The system is structured around Javascript which is an interpreted language and not compiled. As such it takes a lot more CPU cycles to get something done than it would for something written in C and compiled.

2. As best I can tell, they update every indicator with every tick on every chart. So with my own example and having about 10 charts and an average of 4 indicators each, that is a lot os stuff to update. The advantage of this is that you can get see changes in indicator in the sub minute time frame and tick charts are available on everything, it seams.

3. When trading volume goes up such as today when the consumer confidence number came out of Michigan, at 9:55, ticks came storming in. My system completely froze for about 90 seconds. My system scores 5.0 on the Vista performance test which is very acceptable. I run two 1600 X 1200 monitors on an ATI Radeon card.

4. The advantage of esignal is that one has a lot of programmability with the studies and indicators which many systems don't have. That becuase of the interpreted Javascript language.

5. In comparison with the other system I use (and trade on), Schwab Streetsmart Pro (formerly Cybertrader) which is fundamentally an old package written about 10 years ago, esignal is very slow. The Schwab system does not allow user to program any studies. One can select from some pre-programmed ones. One can run 20 windows with indicators on the Schwab platform and no delay at all. HOWEVER, I don't believe they are updateing the studies with every tick, so it has a lot less to process. The Schwab software is no doubt compiled C code and not interpreted which makes it much faster too. The Schwab system does not have near the flexibility in the charting that esignal has. And, of course, the ability for users to program studies is gone.

In the final analysis it is a tradeoff. Having it freeze up when one needs to make a trade or get out of one, is a real problem however.

[sandpiper]

jgr,

The issue reported by clearpicks and I has nothing whatsoever to do with javascripts or indicators, since we both removed all indicators from charts before running the tests. I think you will find that eSignal is written in C++ with just efs study code being javascript.

Having re-run the exact test scenarios I used last night against 10.5, but this time against a re-installed 10.1, I con re-confirm that the issue still persists.

BTW. For information purposes: none of the multi-threading improvements have gone anywhere near the charting functionality.

What would help more than anything with the CPU load issue is not introducing CPU hogging bugs in new releases. And more than anything, keeping customers that do test and report these things in the loop.

Certainly don't want to get on Avery_H's case here because he has been very helpful in other areas. But, the fact is two releases have been done since this issue was first reported and it hasn't been fixed properly (if at all). Why is code that is known to be defective being released at all?

[sandpiper]

jgr,

No, I don't get any script errors, although it does take and eternity to actually post any messages.

Regards.

[jgr]

Sandpiper

The error message went away, just a few hours after I posted that message. A 0.07R chart on one of the fast moving leveraged deritive ETFs, say FAS, seams to really bog my system down, while building the first time. Some are worse than others.

I see the long delays in posting too. Sometimes it times out.

[JayF]

Originally posted by clearpicks
By comparing the CPU usage in 10.1 and higher version, it is obvious that a bug was introduced since eSignal 10.2 cuasing this abnormal CPU usage issue. One month has passed since I reported this issue. Can someone from eSignal confirm that this bug is under investigation and going to be fixed in future release? Thanks. - Clearpicks

Clearpicks,

Our software QA team has spent numerous hours trying to duplicate this issue, but have not yet been successful. I've also spoken with Avery who also has a 4-monitor system setup in his lab, and while he does see a jump to 20-30% at times (on a dual-core system), it recovers and heads back down shortly thereafter. This issue may relate to a video card driver issue.

The good news here is that for the past year we've been working on a brand new version of eSignal that has a whole new look and feel as well as a rewrite of much of the code. This will likely solve this type of issue as well as increase the general performance of eSignal. There will be a lot to look forward to in 2010. Once we have more of a story to share, you'll certainly start hearing about it.

[clearpicks]

Hello Jay,

Thank you for the update. I am afraid if the new eSignal under development as you mentioned share the same charting engine code with eSignal 10.5, this bug would still exist in every future eSignal release and it might unnecessarily waste CPU power ( 20% -30% in AveryH's testing without sctipts running is quite something unnegligible especially in some critical time ). Could you tell me what was modified regarding to the charting engine part in eSignal 10.2 vs 10.1? According to my past experience in programming and doing research, sometimes simply reading and comparing the code is the most straightforward yet effective way to fix a bug. Because the CPU is abnormally busy when new streaming data comming in and without any EFS running or any mouse movement or clicking action, it is very likely that the bug is in the code regarding repainting old bars on the chart. I can not recall when the flashing text bug was fixed. I believe it was only the area overlapping with the last three bars on the chart got redrawn in eSignal 10.0 or 10.1. Did eSignal use any technique such as double buffered paint? If so, was any thing changed regarding this since eSignal 10.2 vs 10.1?



- Clearpicks

[JayF]

Clearpicks,

As mentioned, the new version of eSignal coming next year is nearly a complete re-write. It does not use the same charting code that eSignal 10.5 does. The new version will bring improved performance along with many other fantastic features. We appreciate your patience during this period of development.

jgr,

The slow chart building issue with tick-based intervals is something we've isolated to a server-side issue, and we're working with the server team to address this.

[clearpicks]

Hello Jay,

It is great to know that the new eSignal would rewrite the charting engine. Now it seems I only need to stick to eSignal 10.1 and wait for the new eSignal coming out next year.

- Clearpicks