razzbarry
This is the exact model I was using up to now. I decided to use one big main afl script in favour of using the new debugger, which I like a lot. I hope I will not regret it.
On Fri, Feb 26, 2016 at 9:25 PM, razzbarry@imageview.us [amibroker] <amibroker@yahoogroups.com> wrote:
It is very practical to break your code up in logical segments. I have an auto trading program that is over 5000 lines of code,. I found it very difficult to debug and maintain this in one script or afl module so I broke it up into 50 includes.
Design your overall program into logical steps, Make a flow chart of the overall program defining blocks for the functions it will perform. This will also help with debug or upgrading later with a large program and also allow you to use the includes in future programs you may write. That was why object oriented design was invented in the first place and all large programs today use functions, procedures typically in includes to manage this.The auto trading program I use ruins the afl program from top to bottom every time a tick arrives in the live data feed, Trace shows it processes the AT program about three times a second or when a tick arrives. I have not had any performance problems with it. Now I am using a 6 core Athlon processor. I did not have any problems with it when using a dual core Intel processor either. I did have problems using a single core, old and slow, processor. AmiBroker is really fast!Remember that performance depends on the structure of the program. If / then statements limit the path through the program to only what is needed at the specific pass. Functions are called only when needed.The only caveat with using includes is that they must be inserted in the program before it is needed. IF you try to call a procedure in in an include that is not physically placed above it an error will occur. This is different from C or C++ where prototypes are defined at the top of the program. hen the included code can be placed anywhere. Sadly AFL does not allow that.For debugging use _TRACE in a form something like this so you can tell which part of the program has the problem. Debugging is almost impossible otherwise.if(DebugOn) _TRACE(StrFormat("#, Main, PreInit, Reset= %g, SysInit= %g , sysTime= ", Reset, sysInit) + sysTimeStr );I use a debug statement in every path in the program, at the top and bottom so I can see the entry and exit states.. The first part of the trace statement has "#, Main, where Main is the name of the function block in the program. If it is in an include this includes the name of the include.Debug does impact performance so turn it off when not needed. Also use Log found under the Windows tab. This will show the place in the program where an error exists in run tine.
Barry
__._,_.___
Posted by: "B. Pitatzidis" <bobptz@gmail.com>
| Reply via web post | • | Reply to sender | • | Reply to group | • | Start a New Topic | • | Messages in this topic (9) |
**** IMPORTANT PLEASE READ ****
This group is for the discussion between users only.
This is *NOT* technical support channel.
TO GET TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
This group is for the discussion between users only.
This is *NOT* technical support channel.
TO GET TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
.
__,_._,___
EmoticonEmoticon