Effect of variable name length on Eval() execution speed

[fvisagie]

Hi All,

Some scripts I'm working with have fairly long Eval() strings with some nicely long variable names, such as

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()))

and it occurred to me that at some point these strings need to be parsed.

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

[StainlessS]

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.php?p=1643672#post1643672

EDIT: Thread containing post by IanB on absence of hash table: http://forum.doom9.org/showthread.php?p=1650952#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.php?p=1679864#post1679864

[fvisagie]

That's very useful, thanks.

Below not necessarily related to this thread, nor your current script:

All of it! ;)