Upgrade from Eikon -> Workspace. Learn about programming differences.

For a deeper look into our Eikon Data API, look into:

Overview |  Quickstart |  Documentation |  Downloads |  Tutorials |  Articles

question

Upvotes
Accepted
40 2 1 3

Why is get_timeseries much slower than get_data?

Hi,

I am running an automated script that pulls real-time data as well as historic data. I've noticed however that when using get_timeseries, it is much slower than get_data (almost instant) even if I set the time period such that only one datapoint is retrieved.

Any advice on how to speed it up? The script I am running needs to finish within a few seconds, but the get_timeseries function is slowing it down significantly.

Regards,

Moataz Elmasry

eikoneikon-data-apipythonrefinitiv-dataplatform-eikonworkspaceworkspace-data-api
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
Accepted
40 2 1 3

so it turned out the reason behind the slowness is an issue with my code, I was feeding the wrong list to some loop that was supposed to only loop twice.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
39.4k 77 11 27

It is what it is. I guess it's fair to say that get_data method returns real-time market data faster than get_timeseries method. There are certainly reasons for that, which include real-time market data being closer and more ready available to the Web service that delivers it vs. timeseries of price history as well as a more flat data model for real-time market data vs. timeseries. From the client application side there's not much you can do to speed up the retrieval of timeseries data. Pretty much the only variable you have to play with is the number of RICs in the request. It would certainly be faster to retrieve timeseries for several instruments in one request than in a loop one RIC at a time. What the optimum number of RICs per request is can only be established empirically.
The only other recommendation I can think of is the obvious: limit your data requests to only the data you require.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

I see, that is quite disappointing. The data I was trying to pull sometimes gets historically revised during the weekly publication time. So, I can't get the full revised data as soon as it is released without waiting for 3+ minutes until just 2 weeks of historic data is pulled.

If you're saying that it takes you 3 minutes to retrieve 2 weeks worth of daily closing prices for a single instrument (i.e. 10 data points in total) then it certainly sounds excessive and I'd like to see an example of request you're executing. If it's two weeks of daily history for multiple instruments (how many?) or if it's two weeks of tick history, which can be many millions of data points per instrument, and which cannot even be retrieved in a single request at all, then 3 minutes may not be excessive.

I am pulling 129 RICs and the data is weekly so I am only pulling 2 data points per RIC.

Show more comments

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.