Slow LUA

[Dominik]

Hello,

I have a home-made MCP that communicates with fsuipc using a LUA script, data from MFSM 2020 is saved to a file. Another program reads this data and sends it to MCP displays, e.g. Altitude, etc. After installing the latest version of fsuipc 7.4.13, LUA slowed down terribly, data is sent to displays with a long delay (about 2 seconds). In the previous version of fsuipc 7.4.11, the problem did not occur and data on MCP displays refreshed immediately. Has the LUA refresh rate been reduced? - If something like that is.

 

Dominik

[John Dowson]

There has been no change at all in the lua interface for a very long time.

Slow lua has also been reported before - see:

So I have investigated this before...

What I found previously was that lua scripts (and possibly FSUIPC7 itself) was running a lot slower when FSUIPC7 was started via the EXE.xml method. This is why I changed the default auto-start method to use the MSFS.bat file in version 7.4.12. However, with SU15, I retested this and found that lua scripts were now running at the same speed when started via the EXE.xml method as when started via the MSFS.bat file (or manually started), so I switched the auto-start method back to using the MSFS EXE.xml file in the latest version, 7.4.13.

So, if you are auto-starting FSUIPC7 using the default auto-start method, the EXE.xml, can you try exiting FSUIPC7 and then manually re-start it. Do you then get back to the original lua performance speed? If so, try switching back to the MSFS.bat auto-start method.

Other than that, I cannot think of anything I can do to improve the performance or why it is sometimes running slower. Note also that lua will run a lot slower when lua debug logging is activated.

[Dominik]

I start MFSM2020 then manually start fsuipc v7.4.11 everything works great. I close fsuipc and start v7.4.13 refreshing values on MCP becomes slow. I start v 7.4.11 again and everything works great. I don't change anything in lua code or other settings. If it's not fsuipc's fault then it's very strange. But if you say so then it has to be so.

[John Dowson]

1 hour ago, Dominik said:

I start MFSM2020 then manually start fsuipc v7.4.11 everything works great. I close fsuipc and start v7.4.13 refreshing values on MCP becomes slow. I start v 7.4.11 again and everything works great. I don't change anything in lua code or other settings. If it's not fsuipc's fault then it's very strange. But if you say so then it has to be so.

This sounds quite strange. Can you attach your lua please and I will test here (although I'm pretty sure I won't be able to use your lua directly, I can mimic what it does).

Could you also please test with the attached lua script - its a simple script that logs FSUIPC offsets to a file (and is also available in the example lua scripts provided).
Can you run this lua for a minute or so both in 7.4.11 and 7.4.13 and post/attach the resulting log file (the log will be appended and so the results from both tests will be in the same log file). I am interested in seeing the time-stamps in this file (first column), and see if there is much of a difference in these between 7.4.11 and 7.4.13. If you set lua debug logging (Log -> Lua Plugins) you should see the timestamps between entries increase by a factor of 10-13 or so.

There are no changes between 7.4.11 and 7.4.13 that could affect lua performance, as far as I am aware, so I find this quite puzzling....

John

record to csv.lua

[Dominik]

I am sending the files you requested in the attachment. The PMDG737Zapis.lua file saves data to a file that another program reads and sends this data to the MCP, Overhead and radio Panel. The PMDG737.lua file supports switches. B737 PMDG aircraft.

I hope this will help solve the problem.

Dominik.

FSrecord7_4_13.csv FSrecord_7_4_11.csv PMDG737Zapis.lua PMDG737.lua

[John Dowson]

The output from the record to csv.lua shows this was actually running slightly faster on 7.4.13 compared to 7.4.11.

A change from displaying immediately to taking around 2 seconds does seem a huge difference and I really have no idea what could be causing this change.
I'm not sure what I can do here to look into this.

Could you maybe try and determine where this delay is, i.e. in what lua functions. You could maybe start with lua plugin logging (Log -> Lua Plugins) as this will log every statement. This will slow lua down a lot, but if it is still a lot slower in 7.3.13 with this then this may reveal where the problem lies, otherwise you could add some ipc.log statements when entering/exiting each function and we can compare the time it takes for each function to execute in each version. If you send me the logs for each version I can check them here.

One thing you can also try, if you have not done this already, is to change the WASM ini parameter LvarUpdateFrequency from its default value of 6Hz to VisualFrame. This will improve the rate that lvar updates are passed from the WASM to FSUIPC7.

John

[Dominik]

Hello,

I changed the parameter for LvarUpdateCeequency to VisualFrame in the wasm ini file but unfortunately no improvement. Attached are two log files with the Log -> Lua Plugins option enabled. When creating these logs the delay on the displays is still greater in version 7_4_13

Dominik

FSUIPC7_4_13.log FSUIPC7_4_11.log

[John Dowson]

Looking at your scripts and logs, it looks like:
   - your functions in the PMDG737.lua are taking roughly the same amount of time in both 7.4.11 and 7.4.13. 
   - there seems to be a two second increase in the time it takes for one iteration of the while loop in PMDG737Zapis.lua
          the first loop in 7.4.11 takes approx 17, seconds, and subsequent loops approx 12 seconds
          the first loop in 7.4.13 takes approx 19 seconds and subsequent loops approx 14 seconds

I can take a look in more details at the PMDG737Zapis.lua to see if there is anything there that could cause such a delay, but I think it might be a small increase in time for each line executed, and as there are so many lines in the while loop in this script, it all adds up to quote a bit. I can check the timestamps of the log of this function execution at some point to verify this, but will take some time... This would be easier if you could supply separate log files for the lua scripts, i.e. Log-> Lua Separately

The PMDG737Zapis.lua script doesn't look very efficient - what exactly is this script doing, and why is it executing so much in an infinite loop? 
And why are you communicating between your scripts using files (and why do these files have a .lua extension - they are NOT lua files, better to change these to .txt or .tmp)?
You only seem to be sharing numbers - why don't you use FSUIPC offsets?

I have also gone through all the changes between 7.4.11 and 7.4.13 and can see nothing at all that should affect lua perfomance. I can only think that an update of the windows libraries has caused this. but there is no way I can confirm this. Have you tried 7.4.12 - does that have similar performance to 7.4.11 or 7.4.13? If you don't have this version, you can download from here. It would be useful to know in which version this performance degradation actually occurred.

John

Edited June 12 by John Dowson
Further info added

[John Dowson]

Looking in more detail at the PMDG737Zapis.lua function, it looks like the difference in time to complete one iteration of the loop is due to the time taken to read an lvar.
In 7.4.11, in takes around 15ms to read an lvar's value (ipc.readLvar), whereas in 7.4.13 it is taking around 47ms, so its around 3x slower. As you are reading a lot of lvars, around 100, this 30ms difference adds up, hence the difference in the time it takes for one loop iteration in the different versions.

I believe I added some additional checks/locks in the WAPI between these versions (I will check) to prevent multi-threading issues. These additional locks will certainly slow things down slightly.. I can review these changes to see if I can relax them a bit, but other than that there is not much I can do about this unfortunately.

I would consider re-writing the PMDG737Zapis.lua script if I were you... it seems to be doing a lot of work in each loop - can this not be split-up and separated into different functions or scripts? 

[Dominik]

First of all, thank you for taking such a close look at my case.

The script could definitely be written better. I wrote the LUA script for a ready-made program for handling MCP etc. which works on Xplane. In Xplane I have communication via writing and reading to a file. It's a pity that reading lvar took longer but I understand that you had to make such changes. For now I will work on version 7.4.11 until I modify the program for MCP to work with fsuipc offsets. I checked version 7.4.12 in which LUA works as slowly as in version 7.4.13

Dominik

[John Dowson]

On 6/12/2024 at 4:55 PM, John Dowson said:

I believe I added some additional checks/locks in the WAPI between these versions (I will check) to prevent multi-threading issues. These additional locks will certainly slow things down slightly.. I can review these changes to see if I can relax them a bit, but other than that there is not much I can do about this unfortunately.

I thought I had updated this but my comment seems to have gone... Anyway, I checked this and the additional locks were added way back in the 7.4.0 release, so i don't know why things are slower. Looking in more detail, in may not be just the lvar reads. I will look into this further when time permits, but I can't see any changes between 7.4.11 and 7.4.12 that could cause this, except maybe with library updates (the MSFS SDK and the windows VC++ redistiubutable libraries), which I cannot do anything about.

John

[Dominik]

On 6/17/2024 at 12:31 PM, John Dowson said:

I thought I had updated this but my comment seems to have gone... Anyway, I checked this and the additional locks were added way back in the 7.4.0 release, so i don't know why things are slower. Looking in more detail, in may not be just the lvar reads. I will look into this further when time permits, but I can't see any changes between 7.4.11 and 7.4.12 that could cause this, except maybe with library updates (the MSFS SDK and the windows VC++ redistiubutable libraries), which I cannot do anything about.

John

It would be great if you would look into this in detail, maybe you will find a solution.

Dominik