Stress test using optimize on 1000 stocks daily.

What is the effect of storing all order objects through the entire backtest?

Seems fine to me.
_

Someone might want to add operations to this timing code and maybe turn up something interesting.
Or just use the timing elements in your own code. See if you can locate any cause of a timeout for example.
I believe timeouts have become rare these days. When they do crop up, it would be good to narrow it down to a function.

Here, keeping track of the size of all order objects together as a string.

Timing some operations:
order_optimal_portfolio
get_order
history

2018-11-01 06:31 timing:179 INFO Timings in seconds:  
2018-11-01 06:31 timing:181 INFO   avg  0.156074 low 0.065466  high  1.394015  optimize  
2018-11-01 06:31 timing:181 INFO   avg 14.611943 low 0.648817  high 32.708465  get_order_w_str  
2018-11-01 06:31 timing:181 INFO   avg  0.044873 low 0.031634  high  0.238580  history  

get_order timing high by itself was around 5 seconds, without including the string append (entire 'for' loop, which is get_order_w_str above at 32 seconds). So the string append is around 27 seconds, expensive time-wise. These are from a previous backtest.

Couple of things:
In pipeline, filtering for top 1000 priced stocks, orders totaled 50 MB
Bottom prices instead: 100 MB. The difference is interesting. But that's still only 1% or so of 8 GB.
There are spikes in history every couple of months, however in general looks like it could be even faster over time.
Optimize time ramps up to a peak and then plummets back to normal near end. Odd. Noticed in two backtests.
Click chart legend items to isolate and see that. Use slider to negate smoothing for real values or see log.
Only 1 second though for 1000 stocks.

Overall in timing, normally Quantopian is lightning fast.

Further testing that could be useful: Compare this result to a busiest time of day, whenever that might be.
Timing is modified a bit from the original timing code