MultiCharts: Trading Software for Automated Trading and Backtesting

normally this can't be:

AMD64 3200, 3GB RAM and MC needs about 30% calculation power of this PC resources to show ONLY an 49 share bar chart on @EC.
In the chart window wasn't ANY indicator. Simple bar chart only!

swisstrader,

as I mentioned in a different thread I am having great problems with MC too when it comes to studies. Running on an AMD 64 4000+ with 2 Gigs of RAM MCActiveX.exe likes to take up 90% of the CPU causing the whole system to freeze for a couple of seconds. You can't trade this way!

Compared to TS it's just a joke and the developers should improve it asap, because this way users will surely not switch from TS to MC.

Chris

This hasn't been reported before...
What version are you using? How many bars in that chart? Also, could you please send an example workspace that shows such behavior?

you can build the workspace yourself:
open a simple chart window with data feed by TS:
symbol @EC and 49 share bars with 7 days back
THAT'S ALL. no indicator, no other program opened,
used last version 1.90.449.1165

I have 2 G of ram and 3.06 dual core and it can take an hour for a chart to load from IB. I am getting data only from the first of March and I literally start the chart and go do something else. It too is taking 80 - 100% CPU at times.

Scott, IB is IB. Downloading data from IB is not a question of MultiCharts performance.
It can happen that it doesn't send data to IB's own client just as well (or as bad). This happens - use eSignal if you want a reliable commercial service.

Will work on reproducing the issue reported by swisstrader.

Alex,

I have an in-house application that loads the same data in seconds. In fact, if I start the in-house before MC, it will download the data in seconds and then start MC which may take an hour.

ScottB,

Alex is right if download the data completely new from IB. It took me three days to fill a data gap of two month on several symbols .
But MC is still trying to download data from IB for some days although it's already stored in the quotemanager (maybe it's checking if the data is correct). That might cause the problem that you sometimes wait for hours.

normally this can't be:

AMD64 3200, 3GB RAM and MC needs about 30% calculation power of this PC resources to show ONLY an 49 share bar chart on @EC.
In the chart window wasn't ANY indicator. Simple bar chart only!

I am curious which version you are running. I am not experiencing anything remotely close to this using esignal. I have in addition to my 4 ES charts a Euro chart using 49 vol bars and has 3 months of data. My CPU never gets over 15% However , I am experiencing a lack of responsiveness on occasion that I cannot attribute to cpu usuage. Example , Click to change workspaces and nothing happens. It was like the mouse click was totally ignored as it will not switch. Sometimes it takes two or three mouse clicks. This also happens clicking on other things such as format dialogs etc. Appears to occur totally random.

J~

We'll test this issue and monitor CPU load thoroughly, thanks everyone for the attention.

Is there a way to keep MC from re-downloading data that is already in the cache? I was told to always use on-demand for a chart.

I use MC to avoid having two data feeds (one IB and one TS) but I would love to speed things up in the initial load. IB can be cranky on session boundaries (ie beginning of day, midnight) and I usually close everything and reopen but the delay is driving me nuts.

It is a evident that highly compressed charts are slow (when bar spacing is under 1 pixel and the amount of objects simultaneously displayed on screen is huge). The speed of MultiCharts has been tested and found comparable to TS.

In the picture I attached there's an extreme case to demonstrate - a piece of 7 days of @ES 49 volume bars crammed to fit a small window.
No wonder that switching between such windows is terrible and if such a chart constantly updates, it will be constant pain (bar spacing is 0,026 pixels ).
CPU load when displaying this chart is zero, but when I try to compress, expand, move or do anything to it, CPU load instantly goes to 100%.

Switch bar spacing to 1 and speed will be back to normal.

Scott, to your question: use On-line mode in such a case so it retrieves data once and then connects to live data.

Thanks Alex, that did it - it loaded in about 2 seconds

Scott

Glad this helped, this is something to recommend in all similar cases.

Glad this helped, this is something to recommend in all similar cases.

Then I understand where some of the performance problems come when I overlay charts. But you can't use the 49 Volume Bar spacing if you overlay a 343 volume Chart - you will end up seeing nothing. It's like standing directly infront of the wall and trying to describe the wallpaper .

Chris

This is an area where having a multicore PC may really help. I use <1 pixel spacing routinely and it has never presented a problem. One core handles the drawing and another the incoming data and analytics. I also have high end graphics cards (NVDA 7800GT), which may contribute.

OK., let's buy tomorrow a CRAYSTATION and all is solved!

It is a evident that highly compressed charts are slow (when bar spacing is under 1 pixel and the amount of objects simultaneously displayed on screen is huge). The speed of MultiCharts has been tested and found comparable to TS.

In the picture I attached there's an extreme case to demonstrate - a piece of 7 days of @ES 49 volume bars crammed to fit a small window.
No wonder that switching between such windows is terrible and if such a chart constantly updates, it will be constant pain (bar spacing is 0,026 pixels ).
CPU load when displaying this chart is zero, but when I try to compress, expand, move or do anything to it, CPU load instantly goes to 100%.

Switch bar spacing to 1 and speed will be back to normal.

Scott, to your question: use On-line mode in such a case so it retrieves data once and then connects to live data.

Alex, please, please think about it, what you have written here.
( small hint for you from my cat: THIS ISN'T THE ISSUE!)



-swisstrader

Thanks for the cat photo, but I'm sure that huge amounts of bars with bar spacing under 1 DO slow performance - there is no arguing about this.

If you think there is another issue here, please tell what you suppose it to be.

Thanks for the cat photo, but I'm sure that huge amounts of bars with bas spacing under 1 DO slow performance - there is no arguing about this.

If you think there is another issue here, please thel what you suppose it to be.

Alex,
what is the difference between a compressed chart and a chart with on day on screen under condition that both charts have the same number of days back loaded? NO difference! The number of informations in both charts are the same.
If you get now a new tick from exchange MC has to add this one information in both charts AT LAST BAR ON CHART! How can this need so much PC calculation power?
I have compare it to TS platform: TS needs about 5-7 % performance under same conditions like in MC.
It seems to me, that the issue is causally in the internal OS of MC and with every tick MC updates the complete loaded bars of chart window. (only a guess).
Same with PLEditor crash: after open the editor and work so about 2-3 mins with the editor he reacts immediately on the shortest mouse move on table and will close by this mouse movement. Try it: open PLEditor, and wait 2-3 mins. Then take the mouse in your hand and move it.

-swisstrader

> Alex, what is the difference between a compressed chart and a chart with on day on screen under condition that both charts have the same number of days back loaded? NO difference! The number of informations in >both charts are the same.

This is a mistaken assumption. While the number of bars is the same, the system performance is heavily affected by the number of objects (bars, drawings, lines etc.) on the same screen. Same goes for screen resolution –the higher resolution, the worse performance. This is related to various technical aspects, one of which is optimizing the video output and rendering the active screen.


>If you get now a new tick from exchange MC has to add this one information in both charts AT LAST BAR ON >CHART! How can this need so much PC calculation power?I have compare it to TS platform: TS needs about 5-7 % performance under same conditions like in MC.

Please compare apples with apples. You can’t compare fairly since TS doesn’t allow you to squeeze charts as MC can. I assume it works this way to provide good performance which is not possible with high compression.


>It seems to me, that the issue is causally in the internal OS of MC and with every tick MC updates the complete loaded bars of chart window. (only a guess).

It is not correct. Run a simple test – create a chart with a million bars. Allpy a complex study requiring 30 seconds to calculate. According to your assumption, now on every tick arrival the study must take another 30 seconds to recalculate – that is not so.

>Same with PLEditor crash: after open the editor and work so about 2-3 mins with the editor he reacts immediately on the shortest mouse move on table and will close by this mouse movement. Try it: open PLEditor, and wait 2-3 mins. Then take the mouse in your hand and move it.

The Pleditor crash has no relation to this whatsoever, it’s a separate issue we acknowledge and will soon fix.