SCSS hates gradients?

I noticed that saving my .scss files suddenly got a lot slower. I managed to track down most of the difference to some styles I added, in particular the gradient styles. With the gradient styles included, saving the attached file takes about 12.5 seconds on my machine. With those few lines deleted or commented out, it takes about 2.5 seconds.

I've simplified my setup down to just the single .scss file, there are no others in the entire solution. I also updated to the latest version of Web Workbench just last night, and got the latest Web Essentials just to be sure. None of that seems to have affected the save speed.

Please take a look and see if you can replicate this behavior. I've marked the blocks that I'm talking about with comments like:

/* MINDSCAPE - DELETE THIS BLOCK */

and

/* END DELETE */

Thanks for alerting us to this. This doesn't seem to be a gradients issue -- it appears to be an issue with bracketed expressions, which manifests on gradients because they take the form gradient-expr(arg, arg, arg). We're not sure why it's slow on such expressions, and unfortunately the compilation is somewhat out of our control: we just run the standard Sass compiler under IronRuby, which means this is probably hitting a performance blackspot inside IronRuby. We will do some further investigation to see if we can determine where the slowdown is occurring and whether we can work around it but I can't make any promises right now. Thanks again for letting us know and for the clear and simple repro!

Spoke too soon: it only affects complex bracketed expressions -- in particular the compiler seems to slow down significantly when there are a lot of colours in a bracketed expression. Bizarrely, it affects them even when they're commented out! Something very odd going on inside the compiler here -- we'll keep you informed!

OK, well I'm glad you've got a handle on it. For now I moved all the gradients out into a plain-vanilla CSS file, so it's not a huge issue.

Would the slowdown also affect colors specified with rgba() syntax, background images specified with url() syntax, and similar constructs?

rgba() syntax appears to be considerably faster than #-syntax when I test it. Background images specified with url() syntax don't seem to be affected. So it may just be #-syntax colours that are hitting the slow spot.

Just to update you on this, it doesn't look like there is a quick fix for this. The hotspot is a specific regular expression which performs very badly on .NET; the regex is 470 characters long so it's not something we can easily reverse engineer and make a special case for. Since you have a workaround for the case at hand we're proposing to defer this for now, but if you run into situations where it's not easy to work around, let us know and we'll see if we can improve matters.

Ivan, thanks for the update. That is quite the regex!

I found another workaround, which is basically using string operations to hide the parens from the parser. eg,

.user-notifications {
  background: -moz-linear-gradient + "(bottom, #0869a6 0%, #0972b2 30%, #0a82cc 67%, #0b8fe2 100%)";
  background: -ms-linear-gradient + "(bottom, #0869a6 0%, #0972b2 30%, #0a82cc 67%, #0b8fe2 100%)";
  background: -o-linear-gradient + "(bottom, #0869a6 0%, #0972b2 30%, #0a82cc 67%, #0b8fe2 100%)";
  background: -webkit-gradient + "(linear, 0 100%, 0 0, from(#0869a6), color-stop(0.3, #0972b2), color-stop(0.67, #0a82cc), to(#0b8fe2))";
  background: -webkit-linear-gradient + "(bottom, #0869a6 0%, #0972b2 30%, #0a82cc 67%, #0b8fe2 100%)";
  background: linear-gradient + "(bottom, #0869a6 0%, #0972b2 30%, #0a82cc 67%, #0b8fe2 100%)";
}

Looks awkward, but it seems to work.