`addParent` iterates over Strings, which causes a huge slowdown if require('colors') is used in the codebase

[vjpr]

From a crazy long investigation in Marak/colors.js#151

In parse/index.js:

function addParent(obj, parent) {
  var isNode = obj && typeof obj.type === 'string';
  var childParent = isNode ? obj : parent;

  for (var k in obj) {
    var value = obj[k];
    if (Array.isArray(value)) {
      value.forEach(function(v) { addParent(v, childParent); });
    } else if (value && typeof value === 'object') {
      addParent(value, childParent);
    }
  }

  if (isNode) {
    Object.defineProperty(obj, 'parent', {
      configurable: true,
      writable: true,
      enumerable: false,
      value: parent || null
    });
  }

  return obj;
}

Look at var value = obj[k];...

If obj is a String (such as a selector), its keys will be iterated over unnecessarily. If require('colors') is being used in the codebase, the keys will also include all colors getter methods such as bold, yellow, and most dangerously, the terrifying zalgo. All these getters are being invoked for every string. zalgo uses Math.random() which causes a huge slow down.

This showed up in a CPU profile I was running to debug my slow webpack compile, while using bootstra-loader, and resolve-url-loader which depends on rework.

Removing zalgo sped up my compile from 14s to 7s.

Fix should be simple. Check if its a String and skip it in the for loop.

This should give an instant huge speed up to any webpack and bootstrap-loader users. Dependants are all using semver properly.

[Marak]

Yes. Iterating through String using for loop is not good.

I would avoid the iteration completely, or perform .split on the String and iterate through as an Array.

Cheers!

[vjpr]

Iterating over a String is unintentional, and will be avoided completely in the fix.

[matz3]

Any chance for this to be fixed?
It causes a 4x slow down in our case...

We are using grunt which comes with the colors module, so we don't have a chance to easily get rid of it.

The proposed solution in #89 looks good to me and works fine in our case.