

























for post in Post.find(:all, :include => [ :author, :comments ]) # Do something with post end 3> 避免使用类似 MyModel.find_by_*这样的动态查询。使用 User.find_by_username 这样的 语句可读性高并且容易,但是 也带来多一些的消耗。事实上,ActiveRecord 是在 method_missing 中动态生成这些方法的, 所以会比较慢。实际上被定 义和调用的方法,还有在模型类中做的属性映射,最终都 会转化成一个查询语句然后发送给数据库。所以直接使用 MyModel.find_by_sql 或者 MyModel.find 会带来更高的效率。 4> 无论什么时候最优化的 SQL 查询都是使用 MyModel.find_by_sql。不言自明的,即使最 find_by_sql 要比 find 更有效率(因为无需将赋给方法的 终的查询语句是一样的,使用 各种属性参数转换成 SQL 语句)。如果你正在构建一个跨平台使 用的插件,那需要确认所有的 SQL 能够在 Rails 支持的各种数据库上正确执行,或者就要 用 find 方法来替换。一般来说, 用 find 方法有更好的可读性和可维护性,所以在开始用 find_by_sql 对应用做重构前,需 要做些评测和区分哪些查询 较慢需要手工做优化。 5、将一组操作放在一个事务里:ActiveRecord 会将创建和更新记录的操作封装在一个事务 里,多个插入操作会产生多个 事务(每个插入操作一个事务)。把多个插入操作放在一个事务中处理会提升速度。 原代码: my_collection.each do |q| Quote.create({:phrase => q}) end 优化后: Quote.transaction do my_collection.each do |q| Quote.create({:phrase => q}) end end 或者让任何一次插入操作失败都回滚,这样写: Quote.transaction do my_collection.each do |q| quote = Quote.new({:phrase => q}) quote.save! end end 6、 控制好你的控制器:过滤器是昂贵的,不要滥用它们。 并且,也不用过度使用实例变量, . 如果不是被视图所需要的 7、在视图中多使用 HTML.在视图模板里不要过多使用 helper,每次用 helper 构建页面都会 带来额外的步骤。我们是不是
真的需要使用 helper 的方法来生成一个链接的 html,或者是一个文本框或者表单呢? (这 会让对 ruby 不熟悉的页面设 计者开心的。) 8、 日志记录:对应用进行配置只记录真正有用的信息。 日志是消耗很大的操作,配置不当的 日志记录级别(例如 Logger::DEBUG)会影响产品模式下应用的性能。 9、 GC 补丁:对,不是一个真正的代码发布版本,而是针对 Ruby 的垃圾回收做一个高效 打 的优化补丁,这将较大地提升 Rails 的速度。 10、最后一条:我不提倡过早地做性能优化,如果可能,先对这些优化原则有个意识 (但不 要做得过度).
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。