René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Performance fix for slcan","articleBody":"### Describe the bug\nThere is a performance issue with the way the reads are implemented in slcan.py. \n\n_read() reads serial data one byte at a time via read(1), even when multiple bytes (or complete frames) are already buffered in the OS serial receive buffer. Each read(1) incurs a syscall and, when no data is available, blocks for up to the serial timeout (default 1ms). A typical SLCAN frame is ~27 bytes, so each frame requires 27 separate read(1) calls minimum. This causes per-frame read latency of 50–850ms instead of \u003c1ms (particularly on windows which seem to have sub-optimal serial support).\n\nI'm using CAN-TP over CAN-FD, so I'm pushing this to the limits, which is why the performance issue has shown up.\n\n### Expected behavior\nThe serial is read as fast as possible\n\n### Additional context\n\nOS and version: Windows 11\nPython version: 3.10\npython-can version: 4.6.1\npython-can interface/s (if applicable): Canable2 running SL CAN firmware with FD support\n\n### The Fix\nI'll submit a pull request with a suggested fix that alters the serial read behaviour to be significantly faster.","author":{"url":"https://github.com/aaronfultonnz","@type":"Person","name":"aaronfultonnz"},"datePublished":"2026-02-13T23:11:33.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/2027/python-can/issues/2027"}