Threaded GUI slowing method execution?

[Aaron Hoover]

I have a wx GUI application that connects to a serial port in a
separate thread, reads from the port, and then is supposed to put the
data it finds into a queue to be used by the main GUI thread.
Generally speaking, it's working as expected.

However, one method (that's part of a library I've written to parse
the packet structure of the data that's coming over the serial port)
executes approximately 1000 times slower (50ms vs. 50us) when called
from the serial management thread in the GUI as compared to calling
the same function from within a command line Python script. I checked
it by wrapping the call as follows in both cases (GUI and command
line script):

tic = time.time()
<method call>
print time.time() - tic

All the thread is doing most of the time is sitting around checking
the serial port for waiting data, reading it, and appending it to a
list when it finds it. Then, in the same thread, the method that seems
to be remarkably slow works its way through that list looking for
packets of data and appending the packet payloads it finds to a queue
to be handled in some way by the GUI.

My question is, what am I missing about either threading or the fact
that this is running in a GUI that might explain such a huge slowdown.
I'm sending data over the serial at a true rate of about 24k bytes per
second, or approximately 2 packets per ms. Is it too much to ask to be
able to process this data in realtime from within a GUI (I'm not
talking about plotting or anything - just read it and find packets)?
Like I said, the process pretty much runs in realtime from a command
line script.

This packet parsing needs to happen continuously, so it seems calling
join() to ensure it's not interrupted by the GUI thread, won't work.

Thanks in advance for your help.

Aaron

 

[sturlamolden]

All the thread is doing most of the time is sitting around checking  
the serial port for waiting data, reading it, and appending it to a  
list when it finds it.

Do your threads ever block waiting for I/O? If they do, is the GIL
released while they are blocked?

If they don't, you could add a time.sleep(0) to the loop that polls
the port. It will return the rest of the current time slice back to
the system.














Then, in the same thread, the method that seems