Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Add overloads for cache() that take a size #1591

Closed
mttkay opened this issue Aug 15, 2014 · 4 comments
Closed

[RFC] Add overloads for cache() that take a size #1591

mttkay opened this issue Aug 15, 2014 · 4 comments

Comments

@mttkay
Copy link
Contributor

mttkay commented Aug 15, 2014

We find the cache method to be quite useful, however, it's quite memory inefficient for caching single items since even when passing a capacity of 1, it will create an unbounded replay subject rather than one that actually has size 1.

Memory pressure being a major concern on Android, how would everyone feel about adding more overloads/alternatives to cache that take a size, not just a capacity? e.g.:

Observable.cacheWithSize(1)

which would call ReplaySubject.createWithSize internally, using a BoundedState?

@mttkay
Copy link
Contributor Author

mttkay commented Aug 15, 2014

Actually, nevermind, I think I misread ReplaySubject. This only seems to have an effect on the eviction strategy, so using an "unbounded" replay subject with capacity 1 should be what we want?

The terminology is really confusing here.

@benjchristensen
Copy link
Member

We added the cache(int) overload in 0.20.0-RC3 to provide a hint to the underlying ReplaySubject to optimize memory allocation.

The pull request was: #1303

The idea is that it should allocate only the capacity up front but can grow if more items are received.

We could add a cacheWithSize(int) and/or cacheLast() variant that uses ReplaySubject.createWithSize: https://github.com/Netflix/RxJava/blob/master/rxjava-core/src/main/java/rx/subjects/ReplaySubject.java#L157 if that is shown to be more efficient that the more flexible cache which grows if necessary.

A cacheLast() variant would be similar to doing takeLast().cache(1).

Currently the idea for cache is that if only 1 item is wanted, take(1).cache(1) should efficiently allocate memory.

@benjchristensen
Copy link
Member

@mttkay Is the available functionality sufficient or would you like to discuss this further?

@benjchristensen benjchristensen modified the milestones: 1.0.x, 1.x Oct 7, 2014
@mttkay
Copy link
Contributor Author

mttkay commented Oct 9, 2014

I think it's sufficient, thanks. You can close this out unless someone else feels strong about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants