Re: Which cache to store non-persistent data for a short time?

Michael Herger <slim-b/[email protected]>
Newsgroups gmane.music.equipment.slimdevices.devel
Message-ID <[email protected]>
I select depending not only on the data size, but also eg. how often 
it's being accessed.

>      $client->modeParam

I'm not even sure about this one, but IMHO it's legacy and shouldn't be 
used.

>      Slim::Utils::Cache

That's what I'd use for large amounts of data, and if the data isn't 
often read. It's disk I/O which is slow and keeps the disk busy.

>      $client->pluginData

That's what I'd prefer if eg. a value would be needed often. I often use 
it for client specific data, rather than keeping it in a global 
variable. In particular if that data is read regularly.

Let's take the example of metadata for a remote streaming track:

- the ProtocolHandler's getMetadataFor() is polled every few seconds for 
the currently playing track, if you're using the web UI. Thus I'd store 
the data for that track in $client->pluginData

- the same protocol handler sometimes requests metadata for all tracks 
currently in the queue. That's not requested that often, and is a lot 
more data (# of tracks times the data size per track). Therefore I'd 
store this in the disk cache, as it could be re-used in a future 
session, too.

>      Tie::Cache::LRU

That's what I'd use for small sets of data which are not client 
specific, and which change often, and which would update every now and 
then, without the previous data being useless immediately. It helps me 
keeping multiple values around for a while, without a need to manage 
overall size manually. Things would drop off the list after a while.

Keep in mind that this module is slower than pluginData, as the latter 
is simply a ref to a hash, whereas Tie::Cache::LRU has logic to expire 
things etc. And yes, it's rather old. But LMS is using it and its 
siblings all over the place...


All but Slim::Utils::Cache are in-memory: faster, but higher memory 
consumption, and they don't survive a restart.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.