Slcan speed optimization

[pavel-kirienko]

This parser is much faster. It prevents data loss even on a fully congested bus at 1Mbps.

[bendyer]

Fun!

What is the rationale behind using threading.Thread rather than multiprocessing.Process? I would expect the GIL to negate much of the benefit of the speed-optimized parser when used in an application doing work on the main thread.

[pavel-kirienko]

GIL indeed is an issue, but having a secondary thread simplifies the
parser, and also helps to avoid buffer overruns if the main thread
transiently blocks outside of conn.read().

Do you think using multiprocessing here is a sensible idea?

Fun!

What is the rationale behind using threading.Thread rather than
multiprocessing.Process? I would expect the GIL to negate much of the
benefit of the speed-optimized parser when used in an application doing
work on the main thread.

—
Reply to this email directly or view it on GitHub
#15 (comment).

[bendyer]

I always use separate processes if I'm breaking a task out to improve throughput. In this case the objective is reduced latency rather than increased throughput, but I suspect a separate process will be better for that too.

Using a separate process would probably require socket management be moved to that process, but it also avoids thread-safety problems since it forces looser coupling of tasks (e.g. via queues). I generally find that model easier to reason about than a shared-state+threading approach, although it can be more of a hassle to set up.

[pavel-kirienko]

There are two more data points worth considering.

• The current approach seems to fix the problem, so there's risk that switching to multiprocessing would be solving a nonexistent problem. That said, I fully agree with your coupling argument.
• Multiprocessing does not guarantee that the child daemon thread exits when the parent terminates. This may add all sorts of peculiar issues, especially considering that we care about cross-platforming.

I'm not sure further throughput/latency improvements worth the hassle.

[pavel-kirienko]

@bendyer I propose to accept this implementation since at any rate it offers better throughput than what we currently have in master. It is unclear to me whether it is necessary to tinker with multiprocessing at this point.