Keyboard Shortcuts
Likes
Search
Is caching contract IDs to save time a good idea?
¿ªÔÆÌåÓý
I'm thinking I could save some time by caching contract ID lookups for the same tickers and options that I query multiple times per week.? Once a contract ID is assigned, does it ever change provided the ticker does not change?
|
|
Not sure that there is any meaningful time you can save by caching contract ids, but most of them will be constant for extended periods of time. We have seen only very few symbols change their contract ids and only after major changes to the instruments themselves (such as mergers, acquisitions, or significant changes to the structure of an ETF). As I indicated in a different topic, our framework makes calls for every instrument before any API calls are made that require contract object arguments (such as data subscriptions). That has the advantage that all instrument related error handing is centralized in one module and does not have to take place all over the framework. It also gives you up-to-date tradingHours and liquidHoiurs for the next few days. Having said that, we save/cache the last object for each symbol for off-line processing and for use in our trade simulation. But online API clients retrieve fresh objects upon start and after the end of each trading session. ´³¨¹°ù²µ±ð²Ô |
|
Nick
It only takes one incorrect contract id to ruin your whole week. I can't imagine taking that risk.
toggle quoted message
Show quoted text
If it's the difference between being able to implement your strategy and not, I would suggest refreshing the cache each day as close to the start of trading as possible. On 4/18/2022 1:32 PM, Crow wrote:
I'm thinking I could save some time by caching contract ID lookups for the same tickers and options that I query multiple times per week.? Once a contract ID is assigned, does it ever change provided the ticker does not change? |
¿ªÔÆÌåÓýMy platform has quite a sophisticated contract cache. Each request and its results are cached (including negative results). Cache entries expire at the end of the day. Cached stuff includes contracts, reqSecDefOpt results, and market rules. ? When I started doing this many years ago, contract requests were relatively slow due to inadequate internet connection and ridiculous latency. Now I have fibre broadband to the premises and that's all much better. But given the work involved in developing an effective cache, I'm not sure it's really worth it now, but it's done so I use it. ? Cached queries are practically instantaneous. The place they really make a difference is requests like this: 'give me the call option contract for symbol XXX which is the next expiry with a delta greater than 85'. This involves a lot of contract lookup, and the second time such a request is made for the same underlying (say for a different delta) all the contract information needed is immediately available from the cache: however it's still necessary to do market data requests for a subset of those contracts to get the delta, so the saving is not all that great ¨C just noticeable. ? Richard |
Despair