Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Caching #20

Open
Untit1ed opened this issue May 7, 2015 · 14 comments
Open

Caching #20

Untit1ed opened this issue May 7, 2015 · 14 comments

Comments

@Untit1ed
Copy link

Untit1ed commented May 7, 2015

Just wondering if you have any plans on adding caching support to the handler?

@darrenkopp
Copy link
Collaborator

Are you using the handler exclusively? I hadn't considered adding caching as it's usually only used in the debugging scenario, but I guess it's possible people are using it directly.

@Untit1ed
Copy link
Author

Untit1ed commented May 7, 2015

No, not exclusively, it would be just nice to have some caching even if optimizations are disabled/debug mode, since it might take some time to compile bigger style-sheets (custom bootstrap theme in my case).

@darrenkopp
Copy link
Collaborator

So, the biggest difficulty here would be knowing if the file was still good or not when you are using partials because unfortunately we don't know what's going into the output css file. I'm gonna say this probably isn't feasible at this time.

@Untit1ed
Copy link
Author

Untit1ed commented May 8, 2015

Well it doesn't have to depend on partial files, it could also be something like app.scss?v=UM624qf1uFt8. But I'm not sure if it's even something that can be done with System.Web.Optimization when EnableOptimizations is set to false

@aviatrix
Copy link
Contributor

aviatrix commented May 8, 2015

As of Beta-6 (not it nuget) the time needed to compile scss (foundation by zurb in my case) is up to 2-3 seconds. a huge slowdown occurs when the IIS process is restarted ( due to recompile or web.config change). When this happens an IIS app pool & site process restart is recommended. i'm still investigating as to why is this happening.
So, All in all, caching won't be needed when @darrenkopp fixes the appveyor build & publish stuff :)

@timkishkin
Copy link

I would greatly appreciate caching feature as I'd like to use the handler in production.
My project should support dynamically adding and modifying scss files without restarting the server, so having static preprocessing is not not a good option. Bundles are also not the best solution, as modifying imported files does not trigger bundle update. I see caching in the handler as the only elegant solution, or would you suggest something else? Thanks!

@timkishkin
Copy link

I think caching could be implemented using built-in ASP.NET HTTP cache by providing System.Web.Caching.CacheDependency for all imported files, this way cache would be automatically reset if any of the files are modified. Similar approach is used in dotLess. The list of imported files can be retrieved through SassResult.IncludedFiles. What do you think?

@aviatrix
Copy link
Contributor

@timkishkin this should have been fixed in latest versions of the library.

@timkishkin
Copy link

The slowdown you've mentioned above is apparently fixed, right. But the caching is still missing, I think. I've checked the performance on a bootstrap scss, and the handler takes about 270ms in average to serve the main file. That is good enough, but still way slower than serving static file. It certainly doesn't cache the output, and such handler cannot be used in production, where I would like to use it (see explanation above).

@darrenkopp
Copy link
Collaborator

Are you using the handler directly, or are you using the bundling stuff? I think it's probably possible to add cache watching like that in general for development purposes. things get more complicated with doing something like that automatically for release builds as there can be issues when people run off a network share and exhausting unc resources from file watchers.

@timkishkin
Copy link

Yes, I was planning to use handler directly in production, for reasons I've explained above. The absence of caching prevents me from doing that.

there can be issues when people run off a network share

To be honest, I didn't think about it. Are you sure it would be an issue? I thought that ASP.NET bundling uses file watchers as well, as bundles are auto-updated after source file modifications (I might be mistaken, of course).
Anyway, I'm not planning to use network paths in my case. I think caching might be a good option for me and other people with the same use case.

@aviatrix
Copy link
Contributor

In what kind of scenario do you want to use the caching?

  1. generate once & cache until redeployment?
  2. re-generate every X hours/days
  3. cache until a file (.scss) changes

My ideas :

  1. use bundling and minification
  2. use bundling and minification
  3. this can be quite tricky if you have lots of .scss files in different .css outputs and lots of nested imports , and best case would be to store the user's .scss somewhere in a db or a file and regenerate the output file manually when your system has detected/triggered change. Basically implement this yourself because that will suit your situation better than relying on a generic solution from us that won't quite work for you.

@timkishkin
Copy link

My scenario is the 3rd one. OK, I will consider implementing the cache by myself when I have more time. Thank you for the explanation!

@darrenkopp
Copy link
Collaborator

darrenkopp commented Apr 28, 2017

there can be issues when people run off a network share

To be honest, I didn't think about it. Are you sure it would be an issue? I thought that ASP.NET bundling uses file watchers as well, as bundles are auto-updated after source file modifications (I might be mistaken, of course).

definitely an issue that i've run into before. in general with sass, you end up having a file watcher on maybe like 1 - 2 files (root level scss) which is less of an issue, but once you start adding multiple watchers for single files (referenced by many includes) etc things start getting dicey.

it's probably a non-issue right now though because i forgot that libsass still doesn't work with windows network paths 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants