Is it just me or is it painfully slow and complicated to develop on QC ?

Hi Stephane, sorry you feel like that. It will never fast enough for us, we are doing active research to make it faster. We are even posting bounties to open source contributors to improve the performance. We record the performance of every bit of code and are working to improve them.

There might be a specific issue with your algorithm that we can improve. Please feel free to send it through here and we can suggest optimizations.

What browser are you working on? It should be snappy in Chrome -- but we have noticed people with hundreds of backtests have issues even in Chrome. You can avoid this by not optimizing parameters via backtest.

It might not be much comfort but if the backtest spin up takes a while; remember to factor in the time you'd otherwise spend:

• Buying, downloading, processing and cleaning financial data (months).
• Debugging mistakes in your own backtesting engine, which have patched by the community (years).
• Writing your connection to a brokerage, and then porting your algorithm to work in live mode (months). 

On average we're saving you about 2 years =D vs 30 sec backtest spin up. We'll get that to 5 sec, and we'll add debugging, it just takes time.

Hi Jared and, as always, thanks a lot for taking the time to reply.

#1 Glad to hear that im not an (complete) idiot. In other words, I don't seem to be the only one in this situation.

#2 I completetly agree with you: building my own plateform would take MUCH longer than what im doing right now.

To answer your question: Im using Chrome.

In the end and don't get me wrong, as I once said, I believe QC has a superior product than many of your competitors and that it why I use it to code. I just wish there was a faster and more efficient way to develop (I dare say: Learn to code with LEAN). I think, in the end, being able to use the research app more broadly would probably end up freeing server power for you guys and speed things up for us... does that make sense ? I mean, I think we would all win with a faster/more efficient developement tool and test the final product with a few backtests.

Again, thanks a lot for your time and for building this plateform which I humbly think has a lot of potential.

Hi Stephane,

Our engineers have updated LEAN and the system (specifically the versions of Mono and PythonNet) which has sped things up a bit, and we're making some front-end updates which we expect to result in performance improvements. You can track the progress of these changes and any updates on GitHub.

hi Jack,

I just wanted to thank you for taking the time to update us on the progress. What you guys are doing is not simple but it is extremely appreciated.

Best,

In my case, the execution (backtest) seems to take forever (minutes). The deployment takes ~15s or more. Any ideas?

Muthu, I'm assuming you mean the initial warmup phase of the process? It could be down to the load on the backtesting nodes at the time you submitted the backtest. I find, in general, that live servers are a bit faster than backtest nodes. 

Ok, it is still running. It was deployed around 

10 | 23:53:53: Backtest deployed in 14.63 seconds

just terminated it. Please see what went wrong. New back tests taking longer time too. I was trying to log strike deltas for 2018. May be too much datapoints?

2 | 09:46:49:

Algorithm Id:(486cadc9af0c5a4e5935c8e7debefb9f) completed in 22255.59 seconds at 19k data points per second. Processing total of 421,425,028 data points.

IMHO current problems of QC is not in backtest lags, it's bit annoying but I you can live with it. It's more like your number 2 - you use backtests one after another just to put 2-3 additional self.Debug() calls to better understand what's going on inside. And I clearly see what can help:

1. Live debugging obviously

2. Get more typical examples available. Becauce every newbie doing same things before he understands. You got code for screening QC500 universe but I spent hours to understans how to enumerate all securities from that universe on daily basis. I got couple solutions and got no idea what is more efficient (ActiveSecurities list, UniverseManager class, simply storing in self.symbols after fine filter). For some reasons I couldn't get historical data for that universe unless I call AddSecurity for every new symbol etc. 

Don't get me wrong Jared, I'm not complaining.  You guys doing work and I know you hiring to get it done faster -just some perspective from other end of the pipe. 

Artem: YES !!! I went through the exact same thing. I agree 100%

(I literally went through the exact same situation with the universe management and AddSecurity stuff)

I hope those comments are taken as constructive because, I repeat myself, I believe QC has a far better product than most of the competitors... we just want to be able to code on it efficiently and take full advantage of it.

thanks

Muthu you're processing nearly 500 billion data points, it's not going to get much faster than that I'm afraid. Perhaps it's worth looking at why you're using so much data and if your algo can be optimised to use less than that? 

Didn't realize the options  data resolution is Minute only. I was trying to get familiar with options related API

and logging strike,  price, greeks etc. for 1 year time frame! :)

One thing I can recommend from our experience is to code the final backtest in C# instead of Python. For our backtest, switching from Python to C# literally sped things up 40-50x; it was night and day difference.

Charles Naccio can you share some more about the performance difference? Attaching a backtest from each would be ideal if it is possible.  Were you doing a lot of heavy computation? I decided on sticking with Python because of the wider availability of libraries, but if the speedup is that dramatic I may need to rethink.

I can't post examples of the algos, but what I can say is that we're trading ~2,000 stocks in our daily universe with minute level data. We basically monitor price action throughout the day on a large number of stocks, and trade those intraday that match certain patterns. At the end of each backtest, you'll notice in the logs that it says "Processed x datapoints in y time." The datapoints per second increased 40-50x for us. It was an incredible difference. Given the sandbox like environment that algos run in, it seems C# just runs way faster. For smaller algos, I don't think you'd notice nearly as much of a difference, and in that case sticking with Python probably makes the most sense.

It's not necessarily about the computational speed. The algorithm is counter-intuitive and, in my opinion, a mess. First of all, getting some stacktrace in C# that do not even tell you where in your code there is an issue is really annoying. Starting a backtest just to debug one variable is excruciatingly slow. Second of all, the universes are terribly inefficient. Quantopian could do a universe selection backtest on the entire U.S. equities in 20 minutes or less while Quantconnect takes hours. Ironically, Quantconnect always boasted that they were faster than Quantopian. Well, it doesn't matter if your algorithm has a poor design.  At this point, it would probably be better to rewrite the thing in python and use modern data analysis libraries. The whole process doesn't make sense: register indicator, tradebar consolidator, check if the data is ready. These are all things that do not need to be and make it complicated to develop on this platform.

A quant framework that I used in a quant community about 10 years ago could do around 20 backtests per second for 25 years of hourly data. Utilising a GPU increased it to 1000. Quantconnect can barely do 1.  So yeah, it's definitely not built for performance.

The whole process doesn't make sense: register indicator, tradebar consolidator, check if the data is ready. These are all things that do not need to be and make it complicated to develop on this platform.

So much this. I have never in any other backtester, whether my own DIY scripts or other platforms, had hair tearing frustration just trying to pass the OHLC values around between libraries. It's a completely trivial and common place thing to do, but on QC it's abstracted to the moon and back and there's no good documentation.