cTrader's Performance - Myths and Facts

Before joining cTrader team, I spent years and years optimizing software code that was designed for intensive computations. I was responsible for writing algorithms that on some occasions would take hours or days to complete. Even my academic interests evolve on how to calculate some things faster on solving some of science’s hardest problems. Therefore software performance issues were and still are on my daily schedule. By jumping into the trading platforms world, another very performance sensitive industry, I came across the same widespread preconceptions, misunderstandings and myths about software performance. Therefore, this article is intended in giving a clearer understanding on how a software tool should be judged when it comes to performance.

I will start by tackling a couple of the common myths that are popular in the trading community with some theory and facts and then I will express my opinion on what aspects of a software tool should be important when judging an application’s performance.

Myth 1 - cTrader uses too much memory

There is a common complaint in various forums and discussions that cTrader uses too much memory when compared to other applications. In order to validate if the complaint is based on solid grounds, we will need to explain two concepts a) The purpose of memory in software applications b) How does cTrader memory work.

Facts

The purpose of memory in software applications

Complaining about software using too much memory is usually based on the bias that well performing applications should always use as little memory as possible. This statement is not always true. It is equivalent to complaining that a Ferrari is not performing well because it consumes too much gasoline. When you are talking about household’s budget performance, indeed that might be true, but when you are talking about your Ferrari’s acceleration, then that is not true. Your Ferrari accelerates fast just because it uses that gasoline.

The same principle applies in software tools. Memory exists to be used. We constantly add more RAM to our computers so that software applications take advantage of it. By definition, software’s sole objective is get a set of information as input and deliver another set of information as an output. The output will be the result of a computational process. The main purpose of memory in a software system is to store information during processing, so it does not need to be recomputed. Therefore, a computation intensive or performance sensitive system should utilize as much memory as needed to avoid any unnecessary recomputation.

So why is the misconception that programs with low memory footprint are more efficient so widespread? It mainly exists for two reasons 1) the vast majority of software applications are not performance sensitive 2) the vast majority of applications need to coexist and run at the same time under the same operating system and share common resources. Elaborating on that, you really don’t care if your email will be sent 20 ms or 30 ms after you click “Send”, however you care when when you have 20 applications running and your system is out of free RAM resulting to intensive use of paging and the hard disk, something that will decrease the performance of the system as whole.

In the case of cTrader and trading platforms in general, this is not the case. When the prices are streamed, you need to get them as soon as possible and, when you press the “Buy” button you need to know that it is going to be executed as fast as possible. There are no compromises on this. It is the moment that your software needs to step on the gas! Therefore it should not be stingy in using any resources available and it should use any memory needed to reduce streaming and execution time. During trading race you prefer to use a racing car rather than an eco friendly diesel powered station wagon.

How does cTrader manage memory

In order to explain some of the observations regarding cTrader’s memory behavior, we need to understand the technology on which cTrader is build. cTrader is developed on top of .Net Framework. One of the major breakthroughs that .Net introduced in the software development world is what is known as managed application. One of the major headaches software engineers had in the pre .Net era was memory management. Whenever they had to use memory in their code they had to allocate space and deallocate it when it was not necessary. When they forgot to deallocate memory, this could cause memory leak, something that could cause unnecessary memory usage as described above. .Net solved this issue by automatically deallocating memory reducing memory leaks.

.Net Framework manages memory through a mechanism known as Garbage Collector. The differentiating fact here is that GC is called not whenever something in memory is not in use anymore, but whenever this is deemed necessary by .Net. Nonetheless, this behavior can cause the following misconception, people checking task manager and thinking that the memory allocated by a .Net application is the actual memory used by the application at that moment, while it is not. Most of the times, memory usage in Task Manager displays memory allocated as well as accumulated garbage that will be deallocated as soon as GC is called.

Below you can see a graphical explanation of this behavior. I used JetBrains dotMemory to get a memory profile for cAlgo while running some backtesting on a cBot. In brief, the chart below shows how much memory is used at each time. You will notice an uptrend that begins when I start back testing, which means that cAlgo starts using memory. Then you will notice a sharp decline. This is the exact moment when the GC is called.

This dip is around 500 mb. If you had observed Task Manager just before CG was called you would note a usage of 1 Gb memory by cAlgo. Well, half of it was uncollected garbage. The same can happen at any time running cTrader or cAlgo. Memory usage might seem excessive in the task manager and making you wonder what does cTrader do with all of this memory, while it is just the case that the CG did not consider it necessary to intervene yet.

Summarizing all the above in two points I would advise the following 1) Using a lot of memory is not always a bad thing, as long as it is used wisely 2) Modern software mechanics are rather complicated and cannot be subject to simplistic interpretations. Task manager does not always say the truth.

So why the myth?

Most myths come from real stories so it is fair to state here some truths. Not all applications are using memory wisely. In fact, most applications that use excessive memory are not doing this for performance reasons but merely because of development incompetency. Not all fuel squandering cars are racing cars. In fact, most of them are not. Therefore, hesitation against memory intensive applications is somehow justified. Bad memory management is a sign of other defects as well. A programmer that cannot manage memory well, probably cannot write decent software code in general. Nevertheless, the incompetence of the majority cannot stigmatize the excellence of the few.

Myth 2 - cTrader is built using .Net. It must be slow

Another myth circulating here and there is that applications which are built using .Net are slower than applications compiled to native code e.g. developed using C++. There is some dose of truth in this statement but as we have seen above things cannot be always so simplified.

Facts

Let’s start by explaining why this myth prevails. Indeed when software code is compiled to anything else than native code (the language that the processor understands) it is unavoidable that during runtime there is going to be an overhead translating the non native code to native code. And .Net doesn’t compile applications to native code but to an intermediate language (CIL) which is then compiled to native code through Just in Time (JIT) compilation. There are dozens of reasons why this takes place and it is out of scope of the article to discuss them here. However, all .Net applications start with this small disadvantage. Still, what is important here can be outlined in the following question. When is this performance penalty noticeable and worth considering?

Fast Computers

Modern computers are very fast. Extremely fast. In order for the overhead to be noticeable, you need to make some very very intensive processing and trading is not one of them. See the following picture.

I am running cTrader with 15 graphs open updating in real time, while thousands of symbols are updated on the watchlist and the processor usage averages at around 15% of usage on my low end i3 processor. Any modern processor can easily handle cTrader while delivering much more information than any trader could cope with. The fact that cTrader is not compiled in native code does not affect at all its performance (except if you are still using a Pentium II).

Low processing power needs

The most important part of trading is executing orders on time. But executing an order is not computationally intensive on the client side. More or less is just sending a message with your instructions to a server. To prove my case, I made the following experiment. I made a simple managed application in C# and used FIX API with my demo account  to send 1000 orders to the server at the same time. Then I measured the time it took my computer to send these orders (only sending time, not how much time it took to receive a confirmation since this involves other parts of the system and not only your application).

You can see a video demonstrating my experiment here. It took my low end computer 244 milliseconds to send 1000 orders. This is a sub-millisecond execution for each order for a managed application. Therefore, you can see that there aren't much to gain when using a trading platform built on native code, only some microseconds.

So why the myth?

Regarding the myth, indeed there are use cases where native code is mandatory e.g. rendering graphics for animation movies in Hollywood that might take days and weeks to be completed on expensive hyper computers, or computer games where you need to render as much frames per second as possible. These applications need to execute billions of computations as fast as possible so any gain will make a difference.

But trading is not one of these cases. Trading has other performance requirements that we will discuss in the following section.

What you should really worry about when it comes to performance of a trading platform.

When it comes to trading, the main performance bottleneck is not your computer’s capabilities but your connectivity’s overall performance. The entire trading procedure is about carrying messages between the involved parties. So your main worries should evolve around the network on which you are trading. Therefore you should worry about the following

• Your internet connection. Collaborate with an ISP who provides low latency internet connections. The lower the latency of your ISP, the fastest your message will be delivered.
• Your broker’s server location. This is probably your most important consideration. Before your order is executed it needs to go to your broker’s trading server and then retransmitted to a liquidity provider. If your broker’s server is not conveniently located, you might lose a lot of time and miss the opportunity.
• Your broker’s server performance. Indeed here you need to be aware of the harware’s performance. While it can be ok to run your trading terminal on a low end computer and send some orders now and then, broker’s servers need to handle thousands of orders every minute so they need to be as fast as possible.

Conclusion

When designing cTrader and before making any architectural decisions, we took into consideration all possible scenarios and tried to achieve the best possible balance. Two key decisions were the following.

1. We designed cTrader as a cloud solution to minimize execution time to the minimum. We use state of the art infrastructure worth of millions  collocated with major liquidity providers and aggregators to ensure that your orders will be delivered as soon as possible.
2. We chose to develop cTrader desktop using .Net and pay an unnoticeable performance fee in order to take advantage of the benefits of the framework.  Using .Net Framework we manage to deliver a much better user experience to the customers, more advanced features and software code of higher quality while minimizing the development time to the minimum. That is one of the reasons cTrader gets better and better much faster than any other platform in the industry.

Overall cTrader is considered by serious traders and brokers one of the best performing applications in the market regardless the myths that pop up here and there every now and then.

If you have different opinion or any experience you would like to share, feel free to drop it below :)