Rails Rails 开发环境初次访问 javascript_include_tag 超慢。
* 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 环境没有这个问题。
Reply to
Rei
Rei
暂时我直接把 js 用 conetnt_for 输出到页面上了，其它的框架的 js 直接一次性编译好。 关闭 debug 和 compile. 后面打算用一个 helper 实现，每个页面的 js 独立实现，development 是直接把 js render 到页面中，production 就直接输出 js_include_tag. 然后编译每个 controller 独立的 js 文件。 就是 development 不能用 coffee 了，对我影响不大。 在这个巨大的资源包中，实在是忍受不了这个速度。
另外这个和 win 有关系吗？mac 是不是会快？