Instance snapshotting

[agubarev]

Is it feasible to make an indicator instance cloneable, to make a snapshot and process new values without reapplying full history?

P.S. great library, best by far for Rust

[amv-dev]

Hi!
Thank you for your feedback.

Unfortunately, current implementation does not allow to make indicator's instance clone. I think it is one of the weakest parts of this library. I've started working on this issue several months ago, and there is special branch for it: https://github.com/amv-dev/yata/tree/window-T-ref . It is still WIP as I don't have much free time for now. It lacks on documentation, but it should be pretty useful now.
The main difference is how methods now instantiated inside indicators: totally static.

This branch will be eventually merged into master, but I can't tell when.

[agubarev]

Thanks, I'll look it up. In my opinion think this is very useful for real-time analysis, but even with full recalculation the performance is insane with the tools you're providing. Also, BTW, have you considered adding functionality to get a slice of N most recent/oldest entries in Window without iter(), iter_rev()?
Or maybe a re-usable window across multiple indicators/methods (where it's applicable)?

[amv-dev]

Window holds a simple slice inside (Box<[T]>). You can access it by calling my_window.as_slice(). But you must understand, that values inside this slice are not sorted in the way it's meant to be. As long as window is used in almost every method and indicator, this compromise is required to get as much performance, as possible.

If you need to use the same window inside several indicators, I think, the best way is to create your own indicator. But I don't think this will have any visible effect on performance. The only way it will make performance better is if the size of the slice will be greater than L1 cache of your CPU divided by 2. With f64s inside it must be something like ~4000 elements with 64kb cache CPU.

Some methods also have ability to get inner window: SMA, SMM.

[agubarev]

You're right, I'm overreaching. I do however consider writing a few indicators for a PR. Still formulating ideas and usefulness. Well, thanks again.

[agubarev]

Switched to window-T-ref branch and adjusted my codebase, off the bat I see at least 30+% performance increase, hehe, thanks mate!

[amv-dev]

Great! It's a good sign. I think, the library is on right way :)

[agubarev]

Indeed! :)

Update on relative timing changes:
on a desktop, computation dropped from ~30µs down to ~4µs, often to nanos;
on a cheap VPS 2-vcpu (dedicated) from ~50µs down to ~7µs.

this is an approximate timing of 1 pass to calculate several EMAs (max 200 candles), few BBs, KC, Stochastic in addition to orderbook depth and a few other things, this improvement is epic.

Do you have a todo/wishlist for possible contributions, maybe some roadmap?

[amv-dev]

Unfortunately, I don't have any strict road map. Next big improvement will be indicators refactoring, but it is very complicated task and I worked on it probably since the last summer. Don't have any possible release dates for now.

Actually, window-T-ref branch is now merged in master and published on crates.io. So, I think this issue might be closed.