Serializing $conf array on every page load is expensive

Patch does not apply:
Checking patch public_html/sites/all/modules/contrib/style_settings/style_settings.module...
error: public_html/sites/all/modules/contrib/style_settings/style_settings.module: No such file or directory

After correcting that still:
error: patch failed: style_settings.module:6
error: style_settings.module: patch does not apply

Applied manually and rerolled against latest dev.

Inserting a dsm('I serialized!'); after the serialization code line does indeed show it is not called anymore on each page load. After cache clear a new rewritten CSS file is generated with a new hash tag. We can conclude the patch works as advertised.

Leaving in RTBC for a while before commit.

We've found the same is still true also in the D7 version. Serializing on each page load. This patch would need porting, but it's less important than it seems. Measuring the time with:

$startTime = microtime(true);
  $checksum  = md5(serialize($settings) . serialize($conf) . $change);
$endTime = microtime(true);
dsm( ($endTime - $startTime)*1000 . ' ms' );

shows us times between 0.22101402282715 ms and 0.40006637573242 ms. Even if we have multiple stylesheets, it still doesn't impact the page load by more than a couple of milliseconds.

More interestingly we found that the D7 version rewrites all stylesheets on each pageload if CSS aggregation is turned on. We've opened a new issue for that, #2516920: Stylesheets are rewritten on each pageload if CSS aggregation is turned on. The patch here could possibly be a solution for that.

Thanks.

A difference with before is that a CSS change requires cache clear before being picked up but that seems pretty acceptable.

The same for D7. Note that this patch should be applied after the one of #2525918: Skip rewriting theme CSS files if unnecessary.

Corrected some whitespace errors.

Just to summarize, an additional layer is added to say:
"Hey, do nothing if the css/js cache has not been flushed.".

After that the current mechanism kicks in that says:
"Hey, do nothing if no theme settings have changed AND no variables have changed AND the original CSS file hasn't changed."

We have to realize that we don't live up anymore to what is currently stated on the project page:

Caching of rewritten style sheets by using a checksum derived from the theme settings array (so changes are visible immediately).

Changes will be visible only after at least flushing the css/js cache. It seems more correct and easy enough for projects that declare the Style (CSS) Settings module as a soft-dependency to add so their settings page submit handler:

  if (module_exists('style_settings')) {
    _drupal_flush_css_js();
  }

This way changes are visible right away after saving the form. Otherwise it is necessary to clear the cache after changing CSS variables at:
'/admin/config/development/performance'
which isn't that dramatic either. Most sitebuilders are aware the might prevent changes they made showing up.

Instructions for project maintainers has been added both to the documentation and the README.txt.

Thanks.