Impact of Logging Lua Plugins on Script Response Time

[ark1320 10]

I have noticed that activating log Lua Plugins with FSUIPC7 has a major impact on how quickly MSFS responds to a key input that triggers a Lua script. I have a Lua script that records the ipcPARAM value each time the script is called. The script is called by each of the numberpad num keys such that if called by the 4 key, it records the ipcPARAM value of 4, if called by the 2 key it records the ipcPARAM value of 2, etc. If the script is called when Lua Plugins logging is off I can 'enter' a data value like 245 by calling the script 3 times with the numberpad 2, 4, and 5 keys, and I can do this at a  'normal' typing rate. However, if log Lua Plugins is on, I have to pause for a few seconds between number key inputs (i.e., between successive calls of the script) or else the inputs (ipcPARAM values) are 'missed' for some reason -- perhaps the script does not have time to complete between calls because of an initial logging delay. What is particularly strange, however, is that if Log Lua Separately is on, I can again enter data (repeatedly call the script) at the normal rate -- no inputs (ipcPARAM values) are missed. So it seems something is significantly different in the logging process between logging Lua Plugins and Log Lua Separately, at least on my system.

I don't know if this logging induced delay 'issue' is unique to my system for some reason, or is to be expected when logging Lua Plugins is on, or what. I'm just making what I observed known since I spent a considerable amount of time trying to figure out why I was having certain number entry problems when another user with the exact same plugin was not. It turned out I had log Lua Plugins on, and he didn't. So just FYI.

Al

[Pete Dowson 280]

The logging feature you are referring to is a TRACE.  Between execution of each statement in the script, the Lua interpreter calls external functions to gather the log data (result and line number principally) and sends it to the Log via the main FSUIPC thread. So between each statement there's effectively a change in thread executions with the interpreter held up until its thread is allowed to continue.

So, like tracing things in a compiler development system, the tool is not meant to be used in normal circumstances, but only to debug a problem where the reason is difficult to determine by inspection and very specific logging (via ipc.log).

Pete

 

[ark1320 10]

5 hours ago, Pete Dowson said:

The logging feature you are referring to is a TRACE.  Between execution of each statement in the script, the Lua interpreter calls external functions to gather the log data (result and line number principally) and sends it to the Log via the main FSUIPC thread. So between each statement there's effectively a change in thread executions with the interpreter held up until its thread is allowed to continue.

That explains the script behavior I observed - thank you.

Al