Hi,

Right next to the Compile icon there is a spot with a ms reading. I am taking this to mean how long a strategy takes to execute.

However, the strategy I am running (1 minute) takes much longer than this number. This is from click Go to stuff appearing in the debug window.

When the ms reading is 5,000 ms, the actual count is more like 40 seconds.

Does it take very long to fetch the Bars object (I am assuming this is the only thing that comes down minute to minute)?

How can we separate wait for Bars object time from actual execution time?

Thanks!

User Guide: Strategy Window > Strategy Window Views > Editor

46 ms (Last Execution Time)
Execution time measures the time that it takes the Execute() method to complete. It does not include the time required to retrieve data on-demand, load the amount of data requested in the Data Range control, or any post-processing required for the Performance Visualizers.

Thanks!

I have two related questions:
- Is there a way to disable all PrintDebug statements in a strategy short of placing them all inside ifs checking for a bool EnablePrintDebug?
- Does WealthLab do garbage collection on my strategy? I notice committed memory grows from run to run.

QUOTE:
- Is there a way to disable all PrintDebug statements in a strategy short of placing them all inside ifs checking for a bool EnablePrintDebug?

No. Code your own wrapper method "EnablePrintDebug" and replace all PrintDebug calls in your Strategy. The method would accept a boolean input and would only call PrintDebug if the boolean is true.

QUOTE:
- Does WealthLab do garbage collection on my strategy? I notice committed memory grows from run to run.

Of course yes, it does. How effective is garbage collection in .NET 2.0 is a different question but we hope that the upcoming 6.4 release will bring an improvement with its move to .NET 4.0.

Eugene, do you have an ETA for 6.4?

Let's say mid to late September (Cone will correct me if I'm wrong).

OK, thanks! PrintDebug statements were the culprit. Removing them improves performance ocnsiderably. It also helps to add the ClearDebug() statement when enabling them. Not only is post processing shorter, the Execute() time is also shorter.

Although it seems that garbage collection really was not my problem, can you indicate whether I need deconstructors in each of my classes to make garbage collection work?

Too many PrintDebug statements can be expected to degrade a script's performance.

No, you should not use destructors. Garbage collection is already working.