On Sunday, 23 September 2012 at 12:32 AM, Xavier Noria wrote: > On Fri, Sep 21, 2012 at 8:48 PM, Brian Durand <br...@embellishedvisions.com > (mailto:br...@embellishedvisions.com)> wrote: > > Hi Brian, > > > The Entry model does provide one other feature which I think also warrants > > keeping it around and which is even potentially more valuable than the > > race_condition_ttl. It allows the cache to store nil values. > > You are right. That in itself justifies Entry I believe. We could add a > comment in the source code of the memcached store that documents these two > pros for the next guy wondering about why we use Entry :). I disagree very strongly with this line of reasoning. If you're using memcached as a cache store, you should be relying on its semantics, which is that nil and 'no value' are identical.
Even with the optimised version you're talking storing 58 bytes vs 12 bytes, for a site with a 1GB of stuff to store, should they really need to allocate 5G of cache storage just so people who want to store nil (without using their own wrapper) can? The particular site where I encountered this issue upgraded to a version of rails which used AS::Entry and had their working set expand from 4G to more than 10. Frankly that's not even close to an acceptable trade off. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
