|
PureBytes Links
Trading Reference Links
|
Hello TJ
Your explanation of AFL slow down puzzled me.
Are you comparing the individual #Inlcudes scenario versus the one big #include you mentioned in earlier response or individual #includes versus the external function files I was suggesting?
If talking about the former then it is hardly a fair comparison. Sure the compliler only has to open one #include file but that is not modular programming.
If talking about second scenario then of course there is a fopen/close overhead per function whether code comes from an explicit #include file directive or automatic external libary pull. In either case why would compller access same file more than once?
At code execution time why would there be any difference in performance between code compiled via any of these models. In all cases I would expcet the object code to be fully resolved at execution time and as such there should be no access to defintion files.
Lastly the timings hardly look like prohibitive overhead. At 61 micro secs per fopen/close am I going to notice it ?
Regards
John
----- Original Message -----
From: "Tomasz Janeczko" <groups@xxxxxxxxxxxxx>
To: <amibroker@xxxxxxxxxxxxxxx>
Sent: Thursday, February 12, 2009 11:52 AM
Subject: Re: [amibroker] Re: Run time debugging for includes
> Hello,
>
> One little explanation why implementing the suggestion would make AFL much slower.
>
> If "one function per one file" paradigm was used, it would mean
> extra 48+13 = 61 microsonds overhead for EACH function because
> that is the overhead of file open and file close operation. File access is not "cheap" operation.
>
> That is order of magnitude (10x) higher than overhead of existing
> user-defined function call (which takes less than 6 microseconds).
>
> Of course that difference applies on one use of given funciton in
> one AFL file, and fopen/fclose overhead would play less role
> with 100 calls of the same function, but many functions
> are actually called once or twice per AFL so the overhead
> of proposed solution is completely prohibitive.
>
> Best regards,
> Tomasz Janeczko
> amibroker.com
> ----- Original Message -----
> From: "Tomasz Janeczko" <groups@xxxxxxxxxxxxx>
> To: <amibroker@xxxxxxxxxxxxxxx>
> Sent: Thursday, February 12, 2009 10:23 AM
> Subject: Re: [amibroker] Re: Run time debugging for includes
>
>
>> Hello,
>>
>> Sorry but this suggestion does not make any sense plus
>> it does not bring any benefit to already existing USER DEFINED FUNCTIONS feature.
>>
>> The #includes are STANDARD in C and C++ language.
>> Similar constructs (like "import") exits in Java and other languages.
>> And it is so for purpose
>>
>> Code MUST be included ANYWAY.
>> Specifying WHAT to include allows MORE EFFICIENT execution.
>>
>> There is simply **ZERO** difference between putting all your FUNCTIONS into one include
>> file, placing single #include <all.afl> on top of your formula
>> and calling functions as usual.
>>
>> User defined functions (ALREADY EXITSITNG FEATURE) allows ALL
>> that was suggested below. READ THIS:
>> http://www.amibroker.com/guide/a_userfunctions.html
>>
>>
>> Implementing your suggestion would do just ONE thing save you only from typing 18 letters (#include <all.afl>)
>> and would make program A LOT SLOWER because AmiBroker would
>> need to look and parse hundreds of files searching for "where the user decided
>> to put his functions" .
>>
>> Best regards,
>> Tomasz Janeczko
>> amibroker.com
>> ----- Original Message -----
>> From: "Listsub" <listsub1@xxxxxxxxxxxxxxxxxxxxxxx>
>> To: <amibroker@xxxxxxxxxxxxxxx>
>> Sent: Thursday, February 12, 2009 2:38 AM
>> Subject: Re: [amibroker] Re: Run time debugging for includes
>>
>>
>>> As noted debugging AB with includes is not easy . The nature of AFL makes it quick and easy to write/test simple stuff but as
>>> complexity grows debugging any sizeable AFL project can be quite tricky, particularly if running RT as there is a lot going on.
>>>
>>> "Modular" programming is only catered for in AB by Includes (which is just a soure code copy preprocessor). The AB program
>>> structure model is therefore basically just one big chunck of code - which is why (unless you are very careful what you code
>>> inside Inlcudes) you can get some very hard to find problems (the problems can even change or disappear depending on the roder of
>>> Includes).
>>>
>>> IMO improving AFL to support procedure/function calls to external files would be a big plus to enabling better modular program
>>> design. Specifically:-
>>>
>>> a =xyx(p1,p2) would call the external proc/func "xyz" (unless xyz is defined in current source file).
>>>
>>> The benefits as I see them:-
>>>
>>> 1. #Inlcudes are no longer required for procs/fucntions.Compiler would pull them from library specified via preferences. No more
>>> searching for which Include file is that function in, which version of that was I using .. etc.
>>>
>>> 2. External functions matched by filename. i.e one function name = one filename, no ambiguity, easily portable.
>>>
>>> 3. External files are closed boxes - can only receive/pass data via parameters, return value or global variables. Everything else
>>> inside file is local. No interference bewteen files.
>>>
>>> 4. Faster code development/maint. For example if we have the facility in Preferences to define multiple paths to external
>>> proc/func library it becomes easy to test out changes without having to resort to all the usual suffixing fillenames, changing
>>> calls etc. i.e.
>>>
>>> path1=AB_Function_Library_Test
>>> path2=AB_Function_LIbrary_Live
>>>
>>> So to test out a mod just copy the function file to the Test library, make the changes and test. Compiler searches paths in order
>>> specified so anything with matching name in Test takes precedence over same name in Live.
>>>
>>> 5. Easier debugging? ;-)
>>>
>>> John
>>>
>>>
>>> ----- Original Message -----
>>> From: "jtoth100" <jtoth100@xxxxxxxxxxx>
>>> To: <amibroker@xxxxxxxxxxxxxxx>
>>> Sent: Wednesday, February 11, 2009 2:26 PM
>>> Subject: [amibroker] Re: Run time debugging for includes
>>>
>>>
>>>> Hi all,
>>>>
>>>> debugging includes is not easy and handy in any script language. So
>>>> instead of making the GUI to reduce clicks my suggestion would be to
>>>> reduce possible error cases.
>>>>
>>>> Most errors come from undefined/uninitialized variables. If AFL
>>>> language would have an "OPTION" to require definition of all
>>>> variables then most common errors could be vanished.
>>>> Visual Basic 6.0 never was my favorite language and environment. It
>>>> was for average Joe to do basic level programming. It did not require
>>>> declaring variable just like AFL or any script language. But I had to
>>>> use it years ago. At that time all serious developer started each
>>>> module in VB with "Option Explicit On". This caused an error at
>>>> parse/compile time if a variable was not defined explicitly but was
>>>> referenced anywhere in the code.
>>>>
>>>> How would it help?
>>>> Most probles come from just creating variables by assigning a value
>>>> to an "identifier". However if you misstype an "identifier" or code
>>>> execute in a code path where variable does not get
>>>> defined/initialized you get an error. The worst thing is that these
>>>> errors are hidden until the rearly executed code path is executed
>>>> (typical runtime error). If definition of variables are required even
>>>> these code paths are checked for proper variable usage.
>>>>
>>>> This should be an option for advanced users which is turned on on
>>>> purpose. So all code out there could run with no change.
>>>>
>>>> Variable assignment and definition could be merged to one statement
>>>> like in any modern language (e.g.: var x = 0.5;) This way declaration
>>>> is required and initialization can be done as well.
>>>>
>>>> I know it does not guaranty that all runtime error are gone. But with
>>>> disciplined coding most can be avoided and the need for debugging is
>>>> vastly reduced.
>>>>
>>>> So I would not go for GUI change request but to improve AFL as a
>>>> script language.
>>>>
>>>> Regards,
>>>>
>>>> Y
>>>>
>>>>
>>>>
>>>> ------------------------------------
>>>>
>>>> **** IMPORTANT ****
>>>> This group is for the discussion between users only.
>>>> This is *NOT* technical support channel.
>>>>
>>>> *********************
>>>> TO GET TECHNICAL SUPPORT from AmiBroker please send an e-mail directly to
>>>> SUPPORT {at} amibroker.com
>>>> *********************
>>>>
>>>> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
>>>> http://www.amibroker.com/devlog/
>>>>
>>>> For other support material please check also:
>>>> http://www.amibroker.com/support.html
>>>>
>>>> *********************************
>>>> Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> ------------------------------------
>>>
>>> **** IMPORTANT ****
>>> This group is for the discussion between users only.
>>> This is *NOT* technical support channel.
>>>
>>> *********************
>>> TO GET TECHNICAL SUPPORT from AmiBroker please send an e-mail directly to
>>> SUPPORT {at} amibroker.com
>>> *********************
>>>
>>> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
>>> http://www.amibroker.com/devlog/
>>>
>>> For other support material please check also:
>>> http://www.amibroker.com/support.html
>>>
>>> *********************************
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>
>>
>>
>> ------------------------------------
>>
>> **** IMPORTANT ****
>> This group is for the discussion between users only.
>> This is *NOT* technical support channel.
>>
>> *********************
>> TO GET TECHNICAL SUPPORT from AmiBroker please send an e-mail directly to
>> SUPPORT {at} amibroker.com
>> *********************
>>
>> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
>> http://www.amibroker.com/devlog/
>>
>> For other support material please check also:
>> http://www.amibroker.com/support.html
>>
>> *********************************
>> Yahoo! Groups Links
>>
>>
>>
>
>
>
> ------------------------------------
>
> **** IMPORTANT ****
> This group is for the discussion between users only.
> This is *NOT* technical support channel.
>
> *********************
> TO GET TECHNICAL SUPPORT from AmiBroker please send an e-mail directly to
> SUPPORT {at} amibroker.com
> *********************
>
> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> http://www.amibroker.com/devlog/
>
> For other support material please check also:
> http://www.amibroker.com/support.html
>
> *********************************
> Yahoo! Groups Links
>
>
>
>
>
------------------------------------
**** 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/
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|