You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@ddprrt wrote this article, PostCSS misconceptions, which brought to light a huge performance issue. When running just the large Bootstrap codebase with a single variable substitution, it takes 14 seconds to compile(on my system, 5 seconds for @ddprrt). You can find the test bench that he created, here.
I investigated and found that I was foolishly cloning the the whole root and then flushing it node.clone().removeAll(). I made a ./lib/shallow-clone-node.js helper to fix this problem.
The testbench now runs at 840ms overall. And when I pre-compile the postcss-import step and then run another process transform with postcss-css-variables, it now only contributes 230ms. Still not a stellar performance but a great improvement.
I hope to refactor and rework this whole codebase with postcss-selector-parser which I believe will greatly increase clarity and reduce complexity. The refactor will also give me a fresh start to address performance.
aside: Thank you Stefan(@ddprrt), for putting some umpf into that performance demo and writing about PostCSS. I really enjoyed your article, PostCSS misconceptions, and I have always viewed PostCSS this way.
The text was updated successfully, but these errors were encountered:
Wonderful! Great to hear that you could speed that up 👍
And yeah, PostCSS (plugin) authors are generally aware of the pros and cons ;-) Which is a good thing, I like that they communicate open about it
@ddprrt wrote this article, PostCSS misconceptions, which brought to light a huge performance issue. When running just the large Bootstrap codebase with a single variable substitution, it takes 14 seconds to compile(on my system, 5 seconds for @ddprrt). You can find the test bench that he created, here.
I investigated and found that I was foolishly cloning the the whole
root
and then flushing itnode.clone().removeAll()
. I made a./lib/shallow-clone-node.js
helper to fix this problem.The testbench now runs at 840ms overall. And when I pre-compile the
postcss-import
step and then run anotherprocess
transform withpostcss-css-variables
, it now only contributes 230ms. Still not a stellar performance but a great improvement.I hope to refactor and rework this whole codebase with
postcss-selector-parser
which I believe will greatly increase clarity and reduce complexity. The refactor will also give me a fresh start to address performance.aside: Thank you Stefan(@ddprrt), for putting some umpf into that performance demo and writing about PostCSS. I really enjoyed your article, PostCSS misconceptions, and I have always viewed PostCSS this way.
The text was updated successfully, but these errors were encountered: