Ezra Zygmuntowicz
2/19/2008 6:40:00 PM
Hi~
On Feb 19, 2008, at 8:01 AM, Shot (Piotr Szotkowski) wrote:
> Hello, ruby-talk.
>
> After profiling my code I figured out I might want to attempt some
> caching of results obtained in =91heavy=92 methods. Is there an =
idiomatic
> way to do method-results caching in Ruby?
>
> The first thing that came to my mind as a mean to ensure the cache=92s
> =91freshness=92 is to freeze the object in question. Does this make =
sense?
>
> For example, assume that a Blanket is a Set of Blocks, and
> that there=92s a computation-intesive method =91separations=92:
>
>
>
> class Blanket < Set
>
> def separations
> seps =3D Set[]
> # some =91heavy=92 code that builds seps
> seps
> end
>
> end
>
>
>
> Would the below make sense?
>
>
>
> class Blanket < Set
>
> def freeze
> each { |block| block.freeze }
> super
> end
>
> def separations
> return @seps if @seps
> @seps =3D Set[]
> # the =91heavy=92 code from that builds @seps this time
> freeze
> @seps
> end
>
> end
>
>
>
> I guess my question boils down to what does exactly Object#freeze
> prevent from being modified =96 simply all the properties?
>
> If so, does it mean I can only have one method like the above (because
> if some other method did any freezing, I couldn=92t initialise the =
@seps
> cache when the first call to separations occurs)?
>
> Is there any =91best practice=92 in Ruby
> with regards to caching method results?
>
> Is there any obvious other approach to such caching? (I thought about
> having a @cache instance variable that would get reset on object
> changes, but I=92m not sure how to obtain all the list of methods that
> can change an object =96 i.e., methods that throw error when a given
> object is frozen.)
>
> Thanks in advance for any replies/suggestions/insights!
>
The usual idiom for caching heavy results is something like =
this:
def foo
@foo ||=3D some_long_calculation
end
Cheers-
- Ezra Zygmuntowicz
-- Founder & Software Architect
-- ezra@engineyard.com
-- EngineYard.com