Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
4th July 2014, 11:17 | #1 | Link |
Registered User
Join Date: Aug 2008
Location: Isle of Man
Posts: 588
|
Effect of variable name length on Eval() execution speed
Hi All,
Some scripts I'm working with have fairly long Eval() strings with some nicely long variable names, such as Code:
Eval("MF_INFO" + String(MF_activeclips) + """=Eval("MF_source" + clipno) + " " + String(currentframe) + "=" + MF_Frames2SMPTE(c, clipno, currentframe)""") # ... Eval("MF_ssoffset" + String(MF_registeredclips) + "=" + String(tcstr.MidStr(5, 2).Value() + tcstr.RightStr(2).Value()/c.FrameRate())) What, if any, is the effect of variable name length on the execution speed of Eval() statements at frame serving time? I.e., are these variables somehow tokenised during parsing, or would a given statement execute faster with shortened variable names? Is there any difference in behaviour between Eval() statements forming part of the top-level filter graph vs. forming part of runtime code - the Eval() statements in question are contained in functions invoked by runtime scripts? Thanks, Francois |
5th July 2014, 14:36 | #2 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
The below is based on what I have observed rather than perusal of the sources, if however anyone
gives an alternative view, then I defer to their superior knowledge. When Avisynth looks for a variable name, it does so first in the LOCAL variable name table, if variable name is not found therein, it then looks to the GLOBAL variable name table. It is a simple name table, ie there is no hash involved ('hash table lookup':- a quick lookup based a calculation involving a 'magic' number computed from the name, when the name is added to the list), it simply scans though (I presume) a linked list of names and associated AVSValue's (a variant capable of holding any of the Avisynth variable types [EDIT: in case of Clip and String, is a pointer]). Variables are added to the list at the list head, and so the variables added first and occurring earlier in a script will be at the end of the list and those added later will be found a little quicker. Variable names will be scanned as text strings from the first letter onwards, and so if you have multiple variables with the same prefix, then each of those variables will match up to the point where they do not match the name string being searched for. Because of the previous sentence, it would be marginally quicker to have a text postfix rather than prefix, so that name strings may more likely differ at the beginning and so would quit scanning a particular bad match earlier. Having said the above, there is probably no real advantage to changing your naming system (or variable name string length), although I guess you could do a timing test using eg RT_TimerHP() over a number of iterations. Below not necessarily related to this thread, nor your current script: Also, I think using Eval inside of ScriptClip is tantamount to a sort of Eval within an Eval, it would be somewhat more efficient I think to use pre-instantiated GScript function as posted in one of your other threads, also a whole lot easier to implement deep nesting if/else etc. And, I recommend that you use explicit Last in all ScriptClip code rather than implicit (it can make a significant difference). http://forum.doom9.org/showthread.ph...72#post1643672 EDIT: Thread containing post by IanB on absence of hash table: http://forum.doom9.org/showthread.ph...52#post1650952 So, hash tables not used for either variable name table, nor plugin/script filter/function name tables (although used in AVS+). However, addition, subtraction multiply and divide and other operators are carried out by the script parser and consequently fast, whereas eg BitAnd() is a function and would need be looked up in the function look-up table (and like all built-in's will be at the end of the linked list and slower to access than plugin funcs). http://forum.doom9.org/showthread.ph...64#post1679864
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? Last edited by StainlessS; 5th July 2014 at 19:57. |
|
|