Thoughts on how to write faster broccoli plugins
- Ensure your build method returns a promise, and any file system or network operations are done in an asynchronous fashion when possible.
- Do not share memory between instances of your broccoli plugin. This prevents it from being used in parallel. All data should be in local or instance variables or in the caches or the tmp directory.
- Cache the output of your plugin, if the input is the same and your plugin is n:1 from inputs to output, make sure you aren't rerunning your code.
- Note there are two caching modes, build and rebuild. Build is when you are starting from persistent caches only, while rebuild is when files that you are watching have changed. Both cases need to be optimized for.
- Caching is very important. Learn all about hashes and cache keys here:
- Please remember there is no need for your hash functions to be cryptographically secure. Choose fast hashing functions, like trivial, CRC32, MD5.
- If you are thinking of extending from:
- broccoli-writer, consider broccoli-caching-writer
- broccoli-filter, consider broccoli-persistent-filter
- Do not just use a directory name as the input tree to a broccoli plugin, use UnwatchedDir or WatchedDir from broccoli-source.
- Need to recursively traverse all files in a node?
- Walk and create a list first, then process second, do not walk and process as you go.
- Consider using
node-walk-sync instead of
- Update to the latest versions of any code you are using, especially other broccoli plugins.
- A single poorly performing broccoli plugin can greatly slow down an entire build. Make sure your plugin isn't the weak link in the speedy pipeline.
- Check out heimdall visualizer to see where your build is slowing down: https://github.com/rwjblue/heimdalljs-visualizer https://rwjblue.github.io/heimdalljs-visualizer/ (instructions?)