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.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 4th July 2014, 11:17   #1  |  Link
fvisagie
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()))
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
fvisagie is offline   Reply With Quote
Old 5th July 2014, 14:36   #2  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
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.
StainlessS is offline   Reply With Quote
Old 6th July 2014, 15:35   #3  |  Link
fvisagie
Registered User
 
Join Date: Aug 2008
Location: Isle of Man
Posts: 588
That's very useful, thanks.

Quote:
Originally Posted by StainlessS View Post
Below not necessarily related to this thread, nor your current script:
All of it!
fvisagie is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 13:17.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.