- ago
It take place when I turn on many log values. For example 14K WriteToDebugLog() calls.

What I see:
1. Backtesting time increases a lot.
2. Selecting Debug Log tab takes much time after the backtest (tens seconds).
3. Searching process (within Debug Log tab) works with huge lags (that makes it unusable).

So, the question is: is 14K values is too much? It looks like this issue appeared after the update with searching within Debug Log tab. 14K values doesn’t look too much, so maybe there are some reserves to optimize this?
0
642
3 Replies

Reply

Bookmark

Sort
- ago
#1
Thanks for the bug report.

QUOTE:
1. Backtesting time increases a lot.
2. Selecting Debug Log tab takes much time after the backtest (tens seconds).

Both fixed for Build 10.

QUOTE:
3. Searching process (within Debug Log tab) works with huge lags (that makes it unusable).

I'm afraid there's no room to optimize this considering the huge number of search strings.
0
- ago
#2
I see, thanks, I'll try to use less strings).
0
- ago
#3
Search is pretty laggy even for 300 strings.
I tried Python it took 20 ms to find strings (within 300 string) with certain substring. Python is tens times slower.

Maybe it's highlighting that is this time-consuming.

Some possible ways to solve this:

- Addnig search button, so that searching started not with every new symbol, but with a button pressing. It's not that good but if the speed is slow, this one is better.
- Maybe you should highlight only values within the screen (if it's highlighting that slows down).
- Maybe you could add Next, Previous button so user can jump to the next values (btw, this suggestion would be good anyway, no matter wheather it effects speed of not).
0

Reply

Bookmark

Sort