Unacceptable performance in development

[PikachuEXE]

application-split.css.split2:

//= include 'application.css

But it will regenerate the whole application-split.css every time I refresh locally Which makes testing very painful

I only have @import in application.scss, no = require_self or = require_tree

[PikachuEXE]

Generating the application-split.css also takes too long and failed when I tried to deploy to Heroku

[jhilden]

Are you doing your testing in an old IE? Otherwise the split file should never be regenerated, since it's not requested. Beyond that any performance issues with your application.css should not be related to css_splitter I would think.

Obviously I can't do anything about your Heroku issues without any information.

[PikachuEXE]

I do the test locally (with VM) And the application-split.css is always generated

[jhilden]

Can you elaborate a little more in detail what exactly is being regenerated under which exact circumstances (which requests?, with IE, without IE, etc.)? Because above you said that application.css is being regenerated and now you are saying that application-split.ccs is being regenerated.

[PikachuEXE]

It regenerate application-split.css everytime I reload browser Browser can be any browser Even when asset not changed it's still regenerating

[jhilden]

That's really weird and I have no clue why this would be.

How are you telling that it's regenerating the assets? From the rails server output?

I definitely can't reproduce your issues in the gem's dummy testapp (https://github.com/zweilove/css_splitter/tree/master/test/dummy), here is the rails server output from that app, where you can see the assets are only being generated on the first request:

Started GET "/" for 127.0.0.1 at 2013-09-01 01:52:33 +0200
Processing by TestsController#test as HTML
  Rendered tests/test.html.erb within layouts/application (4.8ms)
Compiled application.css  (1ms)  (pid 31011)
Compiled too_big_stylesheet.css  (1258ms)  (pid 31011)
Compiled too_big_stylesheet_split2.css  (1286ms)  (pid 31011)
Completed 200 OK in 2616ms (Views: 2615.1ms)

Started GET "/assets/application.css?body=1" for 127.0.0.1 at 2013-09-01 01:52:35 +0200
Served asset /application.css - 200 OK (2ms)

Started GET "/assets/too_big_stylesheet.css?body=1" for 127.0.0.1 at 2013-09-01 01:52:35 +0200
Served asset /too_big_stylesheet.css - 200 OK (2ms)

Started GET "/" for 127.0.0.1 at 2013-09-01 01:52:48 +0200
Processing by TestsController#test as HTML
  Rendered tests/test.html.erb within layouts/application (0.2ms)
Completed 200 OK in 11ms (Views: 11.0ms)

Started GET "/assets/application.css?body=1" for 127.0.0.1 at 2013-09-01 01:52:48 +0200
Served asset /application.css - 200 OK (0ms)

Started GET "/assets/too_big_stylesheet.css?body=1" for 127.0.0.1 at 2013-09-01 01:52:48 +0200
Served asset /too_big_stylesheet.css - 200 OK (1ms)

Since I can't reproduce the behavior you describe, I fear that I can't help you unless you can provide a test case that reproduces the issue.

[PikachuEXE]

Let me try it again later Thanks!

Pikachu, Leung Ho Kuen Ruby on Rails Developer

Mobile: 90102748 Email: pikachuexe@gmail.com

2013/9/1 Jakob Hilden notifications@github.com

That's really weird and I have no clue why this would be.

How are you telling that it's regenerating the assets? From the rails server output?

I definitely can't reproduce your issues in the gem's dummy testapp ( https://github.com/zweilove/css_splitter/tree/master/test/dummy), here is the rails server output from that app, where you can see the assets are only being generated on the first request:

Started GET "/" for 127.0.0.1 at 2013-09-01 01:52:33 +0200 Processing by TestsController#test as HTML Rendered tests/test.html.erb within layouts/application (4.8ms) Compiled application.css (1ms) (pid 31011) Compiled too_big_stylesheet.css (1258ms) (pid 31011) Compiled too_big_stylesheet_split2.css (1286ms) (pid 31011) Completed 200 OK in 2616ms (Views: 2615.1ms)

Started GET "/assets/application.css?body=1" for 127.0.0.1 at 2013-09-01 01:52:35 +0200 Served asset /application.css - 200 OK (2ms)

Started GET "/assets/too_big_stylesheet.css?body=1" for 127.0.0.1 at 2013-09-01 01:52:35 +0200 Served asset /too_big_stylesheet.css - 200 OK (2ms)

Started GET "/" for 127.0.0.1 at 2013-09-01 01:52:48 +0200 Processing by TestsController#test as HTML Rendered tests/test.html.erb within layouts/application (0.2ms) Completed 200 OK in 11ms (Views: 11.0ms)

Started GET "/assets/application.css?body=1" for 127.0.0.1 at 2013-09-01 01:52:48 +0200 Served asset /application.css - 200 OK (0ms)

Started GET "/assets/too_big_stylesheet.css?body=1" for 127.0.0.1 at 2013-09-01 01:52:48 +0200 Served asset /too_big_stylesheet.css - 200 OK (1ms)

Since I can't reproduce the behavior you describe, I fear that I can't help you unless you can provide a test case that reproduces the issue.

— Reply to this email directly or view it on GitHubhttps://github.com/zweilove/css_splitter/issues/22#issuecomment-23616227 .

[PikachuEXE]

It seems fine now when I use

= require something

Could be @import slow

[jhilden]

Normally @import from sass-rails should check if stylesheets need to be regenerated. And for functionality, you should definitely not use the require_* directives for Sass files, as you can read here: https://github.com/rails/sass-rails#important-note

If you don't have any strong indicators that this has something to do with css_splitter and some additional details, like your stylesheets or a test case, I would like to close this issue. With the amount of information that is available to me the only thing I can do right now is guess. Please reopen if you can provide additional information.

[PikachuEXE]

OK thanks!