Activity

1. algosfox commented on Oct 21, 2026

   

   algosfox

   on Oct 21, 2026

   Author

   More actions

   Additional findings: CCXT Pro vs. a lightweight WebSocket consumer

   I reviewed the trade-delivery path in CCXT Pro and compared it with my alternative implementation.

   CCXT Pro processing path:

   # Client.receive_loop()
   while len(self.buffer) > 1:
       message, size = self.buffer.popleft()
       size_delta += size
       self.handle_message(message)

   The buffered messages are processed synchronously in a loop. The subsequent path includes JSON decoding, Binance-specific message routing, trade normalization, ArrayCache updates and batch extraction in watch_trades().

   Under high message rates, I suspect that synchronous processing and/or cache extraction may cause a growing backlog and delay delivery to the consumer, potentially affecting other tasks sharing the event loop.

   My alternative implementation:

   async def watch_trades(self, symbol):
       await self._ensure_symbol(symbol)
       await self.start()
       state = self._streams[symbol]
       # Wait for data, then drain the symbol's queue.
       ...

   A shared aiohttp WebSocket transport handles incoming trade messages, parses the required fields and puts normalized trades into per-symbol asyncio.Queue instances. The consumer retrieves available trades directly from its queue, without CCXT's trade-cache and slicing path.

   In my comparative tests, this implementation delivered ticks approximately 3–5 times faster under the tested conditions.

   This suggests that the difference may lie in message processing, buffering or batch delivery rather than network latency alone. The exact contribution of each CCXT stage still needs to be isolated by profiling.

   Could the receive-buffer processing and ArrayCache extraction paths be reviewed for high-throughput workloads? Would an optional low-latency mode with a lighter processing path be feasible?