Slow time response with pipes (Windows) #50
Comments
|
Hi there! I'm a bit confused by what exactly you mean by 'pipes'. Do you mean # Use pipes to the standard streams
self.gdb_process = subprocess.Popen(
self.command,
shell=False,
stdout=subprocess.PIPE,
stdin=subprocess.PIPE,
stderr=subprocess.PIPE,
bufsize=0,
)From what I could understand from (2), you're saying that writing using I'd start by profiling both solutions to check where exactly the extra time is being spent. |
|
What I meant with (2) is that I load a gdb python script with In python, I am just polling the file by checking for an ID number that I pass to the script, so if the file has the same ID I sent it through the custom command as an argument to the python script, it means that the GDB script finished processing the command. This takes around 20-30 ms roundtrip from command to getting the data. In method (1) I use pygdbmi to send the following MI commands
which can take around 400 ms to 1000 ms. Once I have time will check out the profiling suggestion and post the results. I might also consider using C/C++ directly to send the GDB MI commands and compare the latency. Regards |
|
I did some quick tests and from the profiling, I see that what takes most of the time is IoManager.py:104(_get_responses_windows) Makes sense as it has to wait for the response from the stdout. By measuring the time of each GDB command request I got the following times with the method Command Time Name of the script : |
|
I did also a test for the Method (2) I mentioned above, where the only thing I send through stdin of the python From these results, I would say that pygdbmi takes more time as it has to wait for the stdout from the GDB process. From this second test using a custom GDB python script all the processing is done internally by GDB with the GDB python API . This is just my guess as I would need to check the source code of GDB and understand how the python API for GDB works internally to confirm this hypothesis. Name of the script: |
|
I wrote a pull request to fix a different timing issue, but it might help you. The current |
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:
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.
The text was updated successfully, but these errors were encountered: