在2008年7月中旬,追忆被添加到Rails核心。使用的演示是这里。
我没有找到任何好的例子,什么时候应该回忆录的方法,以及每种方法的性能影响。例如,这篇博客文章建议,回忆录通常不应该被使用。
对于一些可能会产生巨大性能影响的东西,除了提供一个简单的教程之外,似乎很少有资源。
有人在自己的项目中见过回忆录吗?什么因素会让你考虑回忆录一种方法?
在我自己做了更多的研究之后,我发现回忆录在Rails内核中被使用了很多次。
下面是一个例子:视图/模板。。
这种用法似乎与上面博客文章中发现的回忆录可能会损害性能的发现相矛盾。
发布于 2009-12-04 14:15:04
我认为许多Rails开发人员并不完全理解回忆录的作用以及它是如何工作的。我看到它应用于返回延迟加载集合的方法(如续集),或者应用于不带参数但基于实例变量计算的方法。在第一种情况下,回忆录只不过是一种开销,而在第二种情况下,它是一个令人讨厌和难以追踪的bug的来源。
我不会申请回忆录
还有其他一些不适合回忆录的情况,比如问题和上面的答案,但我认为这三种情况并不明显。
最后一项可能是最重要的:回忆录根据方法的参数缓存结果,如果该方法看起来是这样的,则不能回溯:
def unmemoizable1(name)
"%s was here %s" % name, Time.now.strftime('%Y-%m-%d')
end
def unmemoizable2
find_by_shoe_size(@size)
end
然而,两者都可以重写,以利用回忆录(尽管在这两种情况下,显然不应该因为其他原因而这样做):
def unmemoizable1(name)
memoizable1(name, Time.now.strftime('%Y-%m-%d'))
end
def memoizable1(name, time)
"#{name} was here #{time}"
end
memoize :memoizable1
def unmemoizable2
memoizable2(@size)
end
def memoizable2(size)
find_by_shoe_size(size)
end
memoize :memoizable2
(假设find_by_shoe_size
没有或依赖于任何副作用)
诀窍是从方法中提取一个纯函数,然后将回忆录应用于此。
发布于 2009-03-30 08:22:56
当一个方法从多个表中获取数据,并在返回结果对象之前执行一些计算,并且该方法在请求中多次出现,则回忆法可能是有意义的。
请记住,查询缓存也是活动的,因此只能回溯那些在Ruby中执行计算的方法,而不是纯数据库获取。
发布于 2011-04-04 21:46:14
也许我的经验是什么时候不用回忆录的一个很好的例子。在我的Order模型中,我回忆了简单的计算结果,即Order#subtotal、Order#tax;以及模型对象,即Order#most_recent_credit_card_used。在后者中,当回溯返回CreditCard对象的方法时,当试图更新回忆录对象的属性时,我会得到“冻结的散列”错误。Order#most_recent_credit_card_used.frozen?当方法被回忆录时返回正确,这当然不是我想要的。
我的离开很简单:将回忆录用于返回简单数据类型(整数、浮点数等)的昂贵操作。但不要在返回复杂对象时使用回忆录,比如模型,尤其是ActiveRecord模型。如果您想更新内存中的那些对象。
https://stackoverflow.com/questions/696338
复制相似问题