[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: [ANN] ncache 0.9

Robert Klemme

9/28/2004 8:33:00 AM


"George Moschovitis" <george.moschovitis@gmail.com> schrieb im Newsbeitrag
news:1096307995.391383.313070@k26g2000oda.googlegroups.com...
> Robert,
>
> first of all, thank you for your comments!
>
> > difficult to track down since nobody expects this (if it's done
> > automatically)
>
> this is not done automatically, the programmer explicitly
> includes a Mixin.
>
> > You're likely to run into name clashes and such
>
> only lru_next/lru_prev/lru_key are added to the class to be cached,
> I think name clashes are very unlikely.

I think otherwise. But this is a free country. :-)

> > Using an Array as list storage comes to mind.
>
> This was the original method used, but in order to make this
> efficient I had to use lookup by pointer AND a lookup by the
> caching key, so I swtiched to a custom structure. If you can
> adapt the code to use an Array and no mixin, I will be
> impressed :)

Yeah, true. Drop the array suggestion.

> Your last idea is rather interesting, but the gain (no mixin) does not
> justify the complexity.

What do you mean by complexity? Storing a single linked list element is
not really something I'd call "complex".

> I use this cache in a simple Fragment caching
> scheme for web applications and it seems perfectly natural to
> write code like:
>
> class Fragment
> include N::LRUCache::Item
> attr_accessor :body, :last_modified, :expires
> ...
> end

*I* would not find this natural. If I were using a LRU cache I'd only
expect to have to provide keys that satisfy the same conditions as Hash
keys (immutable, proper #hash, #eql? etc.) and nothing more. Everything
else makes things unnecessary complicated.

A simple calculation might explain this: if you have the choice of
increasing the complexity in a framework or std lib vs. increasing the
complexity in clients of this framework / lib, the lib side increase
usually generates overall *less* cost than the client side increase simply
because there are usually multiple clients using the same framework / lib
and *each* pays the complexity penalty (which consists of coding efforts,
testing and probably documenting). So if you want to make life easy for
people that you want to use your lib / framework do invest the extra
effort; this will increase the likelyhood of your piece of software being
chosen over some other piece of software.

Regards

robert
5 Answers

George Moschovitis

9/28/2004 12:14:00 PM

0

> What do you mean by complexity? Storing a single linked list element
is
> not really something I'd call "complex".

Hmm, I probably didnt understand your suggestion correctly, can you
elaborate please? I am very intereseted in your idea.

> *I* would not find this natural. If I were using a LRU cache I'd
only
> expect to have to provide keys that satisfy the same conditions as
Hash

Well I find natural that a Cache only accepts Cacheable objects (ie
objects that extend the LRUCache::Item). Like a render that accepts
renderable objects. As you say we are free to dissagree :-)
best regards,
George Moschovitis

Robert Klemme

9/28/2004 12:33:00 PM

0


"George Moschovitis" <george.moschovitis@gmail.com> schrieb im Newsbeitrag
news:1096373667.801902.153440@h37g2000oda.googlegroups.com...
> > What do you mean by complexity? Storing a single linked list element
> is
> > not really something I'd call "complex".
>
> Hmm, I probably didnt understand your suggestion correctly, can you
> elaborate please? I am very intereseted in your idea.

class LruCache
ListItem = Struct.new(:obj,:prev,:next)

private
def create_list_item
begin
return @spare || ListItem.new
ensure
@spare = nil
end
end

def return_list_item(li)
@spare ||= li
end
end

Then use #create_list_item and #return_list_item wherever you create or
release ListItems.

> > *I* would not find this natural. If I were using a LRU cache I'd
> only
> > expect to have to provide keys that satisfy the same conditions as
> Hash
>
> Well I find natural that a Cache only accepts Cacheable objects (ie
> objects that extend the LRUCache::Item). Like a render that accepts
> renderable objects. As you say we are free to dissagree :-)
> best regards,

Although there is some truth in this, a LRUCache is something more general
than a renderer - in fact it comes close to Hash IMHO. So there should be
less requirements on container instances than for a renderer.

Regards

robert

George Moschovitis

9/28/2004 1:07:00 PM

0

> class LruCache
> ListItem = Struct.new(:obj,:prev,:next)
> ...
> end
> end

This is a nice trick! Do you have any idea how I can get rid of the
lru_key
field of the mixin too?

the lru_key is used here:
124: delete(last.lru_key) if size() > @max_items
best regards,
George Moschovitis

George Moschovitis

9/28/2004 1:14:00 PM

0

Hmm i can include the lru_key in this spare element too. Very nice
trick!
Thank you.

Robert Klemme

9/28/2004 1:15:00 PM

0


"George Moschovitis" <george.moschovitis@gmail.com> schrieb im Newsbeitrag
news:1096376843.286908.103730@k17g2000odb.googlegroups.com...
> > class LruCache
> > ListItem = Struct.new(:obj,:prev,:next)
> > ...
> > end
> > end
>
> This is a nice trick! Do you have any idea how I can get rid of the
> lru_key
> field of the mixin too?

class LruCache
ListItem = Struct.new(:key,:obj,:prev,:next)
....
end
end

Then put ListItems into the hash.

> the lru_key is used here:
> 124: delete(last.lru_key) if size() > @max_items
> best regards,
> George Moschovitis

Of course.

robert