vectorbt is a package that combines backtesting and data science. It takes a “vectorized” approach to backtesting using pandas and NumPy. This means that instead of looping through every day of data, it operates on all the data at once. This allows for testing millions of strategies in a few seconds. I did a deep dive in how to use it here: https://pyquantnews.com/1000000-backtest-simulations-20-seconds-vectorbt/
Tick data only (trade by trade), otherwise it will fail no matter what software is used or how fast it is.
Only works for non-pathdependent strategies. And this is nothing new. Pandas and numpy could do vectorized computations for ages, Pandas 2.0 is now even faster and more versatile. No extra package needed.
I'm writing my own thing that is not dissimilar. But I'm using Qt and a desktop interface, writing python code for the backtesting engine is still possible but visualizations are fixed. Some would call it a dated approach. Pandas (including 2.0 with the Arrow backend) is very slow, memory hungry and only works for in-memory calculations, at least from what I can see for VectorBT it doesn't support lazy evaluation. For my case, I'm switching to Polars as it's about a magnitude faster and more versatile. EDIT: Apparently Dask and Ray are supported, which is good but still slower than Polars or DuckDB.
I need a fast tester for options that is capable to test basket-wise (ie. multiple option positions for the same underlying ticker, incl. the underlying itself, as a set) and can give daily results, incl. B/E point(s), MinPL% etc. (till expiration(s), or for a given subset) for a range of the underlying spot, as well a range of involved IVs (all ranges configurable). My own tester (written in C++) can do that all, but is unfortunately still ass-slow... :-( Need something faster, which also makes use of parallelism (ie. multithreading) etc. The download of all options of a ticker takes about 1,3 seconds, but brute-force testing of all 2-leg combinations takes more than 10 seconds. Imagine doing this periodically for 150 tickers.... Each run takes more than 28 minutes... :-(
I do archive the data myself, ie. saving snapshot data by getting them via API (in json format). Then doing the testing on that data by giving a starting point in time, which also can be "now" for realtime/neartime trading. But since the testing is so slow, then of course one can't really speak of realtime... One maybe can do it for a single ticker (then having a lag of only about just a few seconds), but usually one needs to process a much bigger watchlist, to rank them...
Yeah, I already have experience in OpenCL programming, but I think even just simple multithreading would already bring nearly x-fold improvement, where x is the number of CPU threads possible (= CPU cores multiplied by CPU threads/core) as my current solution is just singlethread. I can do that all, but it takes time, and I'm so far coding alone here, intend to form a small company with a small team of some coders/programmers soon, since it's the programming what makes the difference in such algo/auto-trading.... Distributing the testing of each ticker to say 10 CPU threads would mean the testing time would reduce to about just 1/10, ie. it would reduce from 10 to just 1 second per ticker, and regarded enough computing power is available then the said 150 would need just 1 second in total instead of the 25+ minutes done via singlethread... For this of course one would need 150 * 10 CPU-threads... a costly HW investment... A top workstation or even a top server machine, or multiple multi-core computers... Each "dedicated virtual core" at a hoster costs about $10.90/month, so renting 150x10 would cost about $16,350 each month Of course buying some servers would come much cheaper.