Understanding The Vgm.txt File

[BenHarper]

I have a system that uses a master script to load a call flow from a database and uses this info to call a range of sub scripts that return values similar to a function call.

 

I have noticed as the complexity of the master script progresses that there can be up to 1.5 - 2 seconds delay between finishing one subscript and the calling of another.

So i am trying to work through the vgm.txt file to see where the time is being taken to see what i should work on to speed things up.

 

Q. What is the format of the vgm.txt file

142943.04 81 StartLoadedVgs at 10/07/2006 2:29:43 PM [VgMulti v6.0.2322]

I understand that 81 is the line no, and the last bit is a description of whats happening, and that the .04 bit looks to be the number of the module that is called in the order they are being called, but what is the 142943. is this some kind of time stamp?

 

Q. If i have an evaluate module for example, that evaluated to 1, 2 or 3, but only had the true or fail paths.

It first checks for a 1, 2 or 3 path and when it cannot be found follows the true path.

Would it cut down any processing time if I were to create a path for all possible outcomes that could be taken directly instead?

 

 

I understand roughly what the following lines are describing,

fired EV_TIMEOUT_CHECKONSTATE

ScriptEventCode EV_TIMEOUT_CHECKONSTATE, code=9007, state=1501

LsRunWaitTillFinished EV_TIMEOUT_CHECKONSTATE

task completed (shellid=6820, process=20856) vgm=15, iRunWait=1, iRunWait_ExeResult_NextVgm=0

no result file returned from program (VGRUNRESULT_81.TXT or SHLRESLT.TXT)

task completed LsRunWaitChooseNext iNextVgm=24

 

but i would really like to knwo exactly what every bit of the log files means, Do you have any documents describing the log files?

 

Thanks

Ben Harper

[SupportTeam]

Q. What is the format of the vgm.txt file

142943.04 81 StartLoadedVgs at 10/07/2006 2:29:43 PM [VgMulti v6.0.2322]

I understand that 81 is the line no, and the last bit is a description of whats happening, and that the .04 bit looks to be the number of the module that is called in the order they are being called, but what is the 142943. is this some kind of time stamp?

142943.04 is the timestamp in 24 hour time format. After the decimal point the fractions of second is indicated. 142943.04 would be 2:29:43.04 PM

Would it cut down any processing time if I were to create a path for all possible outcomes that could be taken directly instead?

No time would be saved.

 

It's probably best for you to post a trace of the incoming call - we can then see in the trace what is taking up the time.

[BenHarper]

Please find attached the trace of a call as requested.

 

The time i am concerned about is the two seconds between

 

083344.80 7 tw PlayEnd 7 104546 (end of intro sound file played)

083346.35 7 play start ok, lPlayId=109734 (start of first promt file played)

 

As you can see, closely behind the end of the intro play module there, i am reading in an array of variables that are used as paramters when calling the subscripts, One thing i can see straightup is that the intro could play AFTER this read in of these vars as there is just over a second wasted on this vb module and the result return alone and then i could do more of this processing before the call is answered.

 

I think I will be ok to work out how speed things up now you have pointed out that it is in fact a time stamp in the log. (It was actualy pretty obvious after you pointed it out). So if you have a min to give me any other time saving tips, cool. Otherwise I should be right now on my own.

 

Thanks again

Ben Harper

0712vgm.txt

[SupportTeam]

Use the Run_ResultReturn (or Script_Goto) COM functions at the end of the VBscript in the Run VBScript type modules. This will ensure that VG will immediately go to the next module. If Run_ResultReturn etc is not called then VG will periodically check whether VBScript has finished - this is done every 0.1 second in newer versions of VG but in the older version you are using this was getting done every second only.

 

I see that you are using Run_ResultReturn in module [GetSoundFileToPlay] but not in [GetModuleList] - and VG is effectively adding a second delay before checking whether script from module [GetModuleList] has finished, whereas in module [GetSoundFileToPlay] VG progresses onto next module immediately after it's VBScript calls Run_ResultReturn.