Rails Rails 开发环境初次访问 javascript_include_tag 超慢。

wupei1024 · 2018年06月27日 · 最后由 wupei1024 回复于 2018年06月30日 · 307 次阅读
* Environment: development
* Listening on tcp://0.0.0.0:3000
Use Ctrl-C to stop
Started GET "/problem_categories" for 127.0.0.1 at 2018-06-27 14:41:10 +0800
   (1.0ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" ORDER BY "schema_migrations"."version" ASC
Processing by ProblemCategoriesController#index as HTML
  Rendering problem_categories/index.html.erb within layouts/application
  ProblemCategory Load (4.0ms)  SELECT "problem_categories".* FROM "problem_categories" ORDER BY "problem_categories"."lft" ASC
  Rendered problem_categories/index.html.erb within layouts/application (55.0ms)
  Rendered layouts/partials/_topnavbar.html.erb (2.0ms)
  Rendered layouts/partials/_sidebar.html.erb (1.0ms)
  Rendered layouts/partials/_offsidebar.html.erb (1.0ms)
  Rendered layouts/partials/_footer.html.erb (1.0ms)
Completed 200 OK in 258601ms (Views: 258541.3ms | ActiveRecord: 9.0ms)

需要好几分钟才能显示出第一个页面。 现在是puma,我改为其它服务器也试过一样。

我发现时间花在xxxx_include_tag上,即使是一个空文件,他也要花几分钟。 但是只在第一个遇见的tag上花时间,比如同一个页面上有两个,那后面一个也会非常 的快。

第一次打开以后,后面即使我再修改这个js或者scss,也反应的比较快。

倒是不太影响开发,但是比较奇怪这个现象。

也就是说我认为时间并不是花在compile本身上。

production环境没有这个问题。

共收到 7 条回复

config.assets.debug = false 这样倒是可以解决。 但是每次修改js都要compile更是痛苦。

wupei1024 回复

我遇到过这个问题,应该是静态文件编译的问题

lengcb 回复

我是开发环境,关了compile难玩

一般编译慢是因为:

  1. 文件系统慢,例如虚拟机。
  2. 依赖的包太多。
  3. 缓存有问题。
Rei 回复

依赖的包确实太多

Rei 回复

暂时我直接把js用conetnt_for输出到页面上了,其它的框架的js直接一次性编译好。 关闭debug和compile. 后面打算用一个helper实现,每个页面的js独立实现,development是直接把js render到页面中,production就直接输出js_include_tag. 然后编译每个controller独立的js文件。 就是development不能用coffee了,对我影响不大。 在这个巨大的资源包中,实在是忍受不了这个速度。

另外这个和win有关系吗?mac是不是会快?

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册