Optimize getting Price data #14
Comments
|
Good idea, I thought about this myself. I would love a PR on this. |
provinzio
changed the title
|
Ill try to implement it. Via forks or Branches? What Do you preferr? |
|
Forks |
|
are self.books.operations sorted by date? |
|
No. Just inserted in order of the different files. |
|
My changes are made in the prices class and that is called in taxman, so if it is sorted before Evaluation it should be fine. |
|
But they are only sorted locally. Have a look at the code. Line 151 in 5a4ab99 |
|
Hi guys, I'm not sure if below issue is related to this issue or not, anyways I wrote, please tell me if I've to create a separate issue for this one. Recently I tested the CoinTaxman with my Kraken trading history and I saw that script's price data isn't same as the real trading one. Because it gets price closest to the given timestamp and most of the time this is not precise. For example, I sold dogecoin for 0.400000, but price data gets price as 0.401000 from kraken api and that's why it calculates my gains in the end a bit wrongly. I'm just curious and have some questions about this issue, how to fix it and overall your opinions why you used certain methods:
Many thanks! |
Not the scope of this issue. This issue is just about getting prices from the API regardless of the CSV input. You might want to create a new issue for this and adjust the implementation of the
Might have been slipped through. When it's possible, I think it is the best idea to get it directly from the csv file.
I am not sure about this. If the information is there, this might be possible. But most of the time it's not, because of missing information. For example, (really old) historical prices are most of the time not available as single transactions, but just as 1-minute-candles or "bigger". |
|
To address the problem stated above, we could evaluate the price from the CSVs, store it in the operation, and later only fetch the API price data if we don't have it in the right fiat (EUR)? |
|
you seem like my second brain^^ my solution is/was very similar |
|
xD Let me know when/where I can help. Edit: #96 |
this will be almost seperate from my current pr and i will make a seperate pr for that. when that is merged i only need to edit my current pr so it also uses price data already on disk (should not be that hard) |
Currently the price is calculated by getting the data for 60s from binance and then an average is made from these 60s.
Thus for every trade 3 calls are made to binance if i'm correct (buy/sell/fee) wouldn't it be easier to get the data for a larger timeframe for some coins (e.g bnb for fees and comissions) generate a lot of small transactions within a time frame.
I do not know when exactly the prices are calculated but a simple idea from my side:
1.group transactions of one coin in timeranges which are under one hour (max range on binance)
2.download the needed timerange
3.select the 60s needed for the calculation of the prices and calculate the prices and save to the db
4. maybe cache the api timerange if needed again (dunno if useful)
this could reduce the amount of api calls from for ex. bnb from 1 per entry to about 1 api request per 5-6 entries for bnb
if you have many entries (for ex 8000, around half or more are bnb,mostly due to comissions and fees) it would take around 5-6hours for the prices to load (2s per call) and if it would be possible to optimize that with stated algorithm it would maybe only take 3h)
if there is a better way to get this data would also be good for example get the ohlcv data from binance for the 1m timerange, cctx is a good lib for that, it works with many exhanges or just use: https://binance-docs.github.io/apidocs/spot/en/#kline-candlestick-data . on binance you can request 1000 1min candles with a single request if i'm not wrong, which would be alto faster.
The text was updated successfully, but these errors were encountered: