# Delay in continuous connections

**URL:** <https://brian.discourse.group/t/delay-in-continuous-connections/509>\
**Category:** Feature requests\
**Created:** [29 October 2021 15:50 UTC](https://brian.discourse.group/t/delay-in-continuous-connections/509 "2021-10-29T15:50:34Z")\
**Posts on this page:** 1\
**Showing post:** 16

<div class="post-metadata">

**Author:** ![rth](https://yyz2.discourse-cdn.com/free1/user_avatar/brian.discourse.group/rth/32/16_2.png) [@rth](https://brian.discourse.group/u/rth)\
**Post date:** [16 January 2022 15:58 UTC](https://brian.discourse.group/t/delay-in-continuous-connections/509/16 "2022-01-16T15:58:24Z")

</div>

One more thought on that.

My realization of delays, as a single huge table, can work if we need delays which are different, but not so different. If a chunk of the table where needs to be read is fit into cache, this will should give the optimal performance.  
 ![g2147](https://global.discourse-cdn.com/free1/uploads/brian/original/1X/d6e59d99029f394ace710159df75e2079d069e3b.png)

In other words, there may be a few tables for short, medium, and long delays.  
It seems the same appraoch as in [lookup-tables implementation](https://brian.discourse.group/t/lookup-table-approximator-for-brian2/478) ([code is here](https://github.com/rat-h/lut4brian)) can be used.

---

_[View the full topic](https://brian.discourse.group/t/delay-in-continuous-connections/509)._