Tomasz
Could please you expand on your reasoning/comments re #include and program structure.
My understanding:-
1. #include is a straightforward preprocesor directive to copy in source code.
If a program is split into 5 inlcude files i1 - i5 then after preprocessing the source file with #includes
the compiler sees a simple concatentaion i1+i2+...i5 i.e identical source code block to original program. The only overhead here is locating and reading the #include files from disk. The ovehead is purely related to pre-processor and not execution of code? (The documentation refers to impact on execution time).
2. The cache mechanism simply avoids #include file re-reading by the preprocessor and has no effect on execution time.
I am puzzled why you advocate only using one or two #includes and big main file? Logically there should be no impact on performance using multiple inlcudes. In any language a system developer will always want to use whatever features are available for modularisation. The benefits of building systems using the "Lego brick" approach are many. When developing trading systems we are constantly re-using functions we have developed over time and stitching them togther with trading logic code. As soon as a piece of code becomes generally (or potentially) useful it it is turned into function and placed in library. For me this is the natural and most efficient way to develop and I see others on this gorup who follow similar approach. The approcah of using huge single main program seems unworkable to me.
Thanks
JR
Hello,
Thank you very much for your e-mail.
Normally it is not re-loaded unless you use #pragma nocache
Best regards,
Tomasz Janeczko
amibroker.com
Tomasz
Curious to know why #include incurs any execution performance hit. I would have expected any #includes to be pre(processed) once only or is this not the case?
John
On 18/02/2016 12:55, Tomasz Janeczko groups@amibroker.com [amibroker] wrote:
Hello,
Thank you very much for your e-mail.
It is wrong approach. AFL is not C/C++.
C/C++ programmers tend to create hundreds of small files.
Don't do that in AFL. One, two #included files are good choice.
In AFL #includes are intended to be used only for
well-tested and already tested "library" functions that are used in MANY formulas.
(say you have an indicator that you want to use in many places).
Any under-development code should be in the main file.
That simplifies a lot of things.
Managing 15000 line file is not a problem. There is a code folding,
bookmarks, etc.
I don't know what you are doing but 15000 lines in AFL?
Are you doing some kind of machine learning or neural networks?
If so, personally I would put that in DLL.
Best regards,
Tomasz Janeczko
amibroker.com
On 2016-02-18 09:30, 'B. Pitatzidis' bobptz@gmail.com [amibroker] wrote:
I am trying to make my scripts very modular. Small main programs with lots of functions.
Actually my main afl sript is less than 20 lines. Right now my project totals about 1500 lines and I estimate that it will grow to more than 15.000 lines.
Is it a design flaw to use many #include files? I find it very impractical to have a huge afl script with 15.000 lines.
The documentation of the #include warns about a drawback of using #include:
"Note 2: using #include command may slow down formula execution even considering the fact that AmiBroker tries to include only once and cache pre-processed text"
https://www.amibroker.com/guide/afl/_include.html
I have not benchmarked it, but I hope the delay is not much.
Lately I discovered that the new AB debugger will not allow breakpoints in included files. This rules out the use of the debugger for my kind of design.
This made me think that I might be doing something wrong.
Posted by: jr-sw <jr-sw@liberator-systems.co.uk>
| Reply via web post | • | Reply to sender | • | Reply to group | • | Start a New Topic | • | Messages in this topic (14) |
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