Slow time response with pipes (Windows) #50
Description
I am testing a program I developed for a Microcontroller with a Cortex-M4 CPU. As I need to read/write some specific variables in real time I decided to develop a GUI and use the xPack Qemu ARM software. This SW allows to emulate the microcontroller and interact as well with GDB. I am using pygdbmi to interrupt the program, write data from the GUI and read data and display it. I noticed the execution time of the complete process (interrupt >-read-memory-bytes>-write-memory-bytes>continue) takes around 1-0.6 seconds. As this represents lag in the GUI I decided to check if I could decrease the latency.
As I found out that there is support for GDB with a python API I created a script with a custom command that does what I need (interrupt>read>write>continue). Within the python script I measure the time it takes to execute and it was around 0.01-0.02 seconds. As I still need to integrate it to the GUI I tested two approaches:
- Use again pygdbmi and call the custom command I made in the python script. The response from the command is parsed through the pygdbmi library and the latency was between 1-0.4 seconds, which is a minor improvement.
- Use a file as a pipe and check if the latency comes from the pipes. In the python script for gdb I added method that writes a json file with the data I require. The only interaction with pipes in this case is to write to the standard input and send the command to the gdb process. To know if the script has finished I poll instead for the data contained in the json file. To my surprise this reduced the latency to almost the same I had by manually executing the python script (0.02-0.03) seconds.
So from these results and for my purpose, using files instead of pipes to retrieve the gbd response and the python script support for gdb I was able to have a faster GUI response for my simulated MCU. I could not test the results in Linux as I had troubles using a precompiled gdb with python support for my specific target (arm-none-eabi-gdb).
As I do not have experience with how pipes in Windows work I am not sure if this could be a issue related with windows pipes, the way pygdbmi gets responses from pipes in Windows , if the GDB Machine Interface is too slow or if my implementation is not as it should be. Just wanted to post the results of these experiments as maybe this can become useful to look for ways on reducing latency when interacting with GDB.