cache

117 Commits 2 Branches 2 Tags

3 Commits

Author	SHA1	Message	Date
Matt Keller	bf414c412e	Performance was suffering with very large caches, when the cache was under maxItems pressure. Reverted the LRU handler back to the first iteration: lazy deletion via the janitor, with bulk removal.	2015-03-08 11:50:57 -04:00
Matt Keller	b60c6ee2c8	Consistency.	2015-03-08 09:23:24 -04:00
Matt Keller	f66ee0bbc6	Injected LRU capabilities that simply: * ensures that when an item is added, if the number of unexpired items >= maximum number of items specified, the oldest (based on ACCESS) is expired * when an item is "gotten", or "set", the access time is updated The existing janitor system is unchanged, and used to actually delete the items. The only change from a consumer standpoint, is one addition parameter at the end of a "New" call, that specifies the maximum number of items to allow, or 0, if you want to disable the LRU at all.	2015-02-27 15:57:16 -05:00

Author

SHA1

Message

Date

Matt Keller

bf414c412e

Performance was suffering with very large caches, when the cache was

under maxItems pressure. Reverted the LRU handler back to the first
iteration: lazy deletion via the janitor, with bulk removal.

2015-03-08 11:50:57 -04:00

Matt Keller

b60c6ee2c8

Consistency.

2015-03-08 09:23:24 -04:00

Matt Keller

f66ee0bbc6

Injected LRU capabilities that simply:

* ensures that when an item is added, if the number of unexpired items
>= maximum number of items specified, the oldest (based on ACCESS) is
expired
* when an item is "gotten", or "set", the access time is updated

The existing janitor system is unchanged, and used to actually delete
the items.

The only change from a consumer standpoint, is one addition parameter at
the end of a "New" call, that specifies the maximum number of items to
allow, or 0, if you want to disable the LRU at all.

2015-02-27 15:57:16 -05:00