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 does not work #15

Open
buschtoens opened this issue Feb 3, 2015 · 4 comments
Open

Caching does not work #15

buschtoens opened this issue Feb 3, 2015 · 4 comments

Comments

@buschtoens
Copy link
Collaborator

When processing huge or lots of .svg files, the build time gets extremely slow with the default configuration. The problem vanishes, when the optimization is disabled: optimize: false

This has two possible causes:

  • If svgo is enabled, the caching doesn't work properly.
  • The caching doesn't work at all.

Expected behaviour: Each .svg file is tracked individually and only re-processed, if it actually changes.

I will look into this. Originally reported in #14.

@buschtoens buschtoens added the bug label Feb 3, 2015
@buschtoens
Copy link
Collaborator Author

From the broccoli-caching-writer docs:

Adds a thin caching layer based on the computed hash of the input tree. If the input tree has changed, the updateCache method will be called, otherwise (input is the same) the results of the last updateCache call will be used instead.

So, seems like the whole input tree is re-processed, if even only one file changes.

@buschtoens
Copy link
Collaborator Author

I submitted an issue in broccoli-caching-writer.

I believe that caching files individually is probably out of scope and we will have to find an alternative or ship our own. I added the help-wanted label for this reason.

@buschtoens
Copy link
Collaborator Author

We can probably use broccoli-filter. I'll branch off in my fork and test something out.

broccoli-coffee is a good starting point.

@rlivsey
Copy link
Member

rlivsey commented Feb 3, 2015

Random (possibly crazy) thought, we're currently compiling n:1 which means we don't get the caching for free, could we compile 1:1 instead?

Maybe instead of compiling down to the one registry file, we compile a JS file per SVG which exports the SVG string:

// /svgs/path/to/svg.js
export default "the optimized SVG string here";

Then in the helper we can do something similar to ember-load-initializers to require the SVG as needed.

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

No branches or pull requests

2 participants