What level of delay does Python do for a high-frequency trading system?

Latency refers to the tick to trade. You can allow a few core functions to be implemented with Cython or direct C.

Reply content:

I'm not familiar with Python, but I can offer some ideas.

First do a basic test, take two times of system time, precision in nanoseconds, see how the delay. Let's take a look at a plain C code:

#include 
  
   
    
   uint64_t nanotime(const struct timespec *ts){   return (ts->tv_sec * kT_ns_in_s) + (ts->tv_nsec);}uint64_t    n=50000;uint64_t    sum=0;uint64_t    latency=0;for (i = 0; i < n; i++) {    clock_gettime(CLOCK_REALTIME, &start);    clock_gettime(CLOCK_REALTIME, &end);    sum += nanotime(&end) - nanotime(&start);}printf("Latency: %d ns\n", sum / n);
  
   

The more realistic 1ms level, if you use the Python ready-made library (Urlib, request) to receive data at least 100US levels of latency, the general trading system requires multi-threading, Python's Gil will increase the delay, And when trading is busiest, Python's GC is more likely to occur because it handles a lot of data. Writing the core with C or Cython does not improve much, because the Python delay is due to language design rather than computation. Of course, these problems can be improved, such as to do a set of TCP connection programs or something, but these are not much easier than writing C + +.

In addition to the above answer in the time test is not necessarily representative, in a simple loop test time words compiler and CPU will do a lot of things you do not think, the results will be much worse than the real value.

