Skip to content

Instantly share code, notes, and snippets.

@gitgrimbo gitgrimbo/$Dojo.md
Last active Dec 25, 2015

Embed
What would you like to do?
Building https://github.com/csnover/dojo-boilerplatewith various settings / runtimes.

Dojo stuff.

Building https://github.com/csnover/dojo-boilerplate with various settings / runtimes.

Run from within Git Bash.

Processor Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz Memory (RAM) 6.00 GB

--------------------------------------------------

java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Java HotSpot(TM) Client VM (build 20.45-b01, mixed mode, sharing)

java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b109)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b51, mixed mode)

java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b17)
Java HotSpot(TM) Client VM (build 23.25-b01, mixed mode, sharing)

--------------------------------------------------
    optimize: 'closure',
    layerOptimize: 'closure',
--------------------------------------------------

Java 1.6.0_45
    errors: 0
    warnings: 53
    build time: 81.211 seconds

Java 1.7.0_25
    errors: 0
    warnings: 53
    build time: 72.85 seconds

Java 1.8.0-ea-b109
    errors: 0
    warnings: 53
    build time: 58.023 seconds

Node v0.10.17
    errors: 0
    warnings: 53
    build time: 81.27 seconds

--------------------------------------------------
    // This option defaults to "" (no compression) if not provided.
    optimize: '',
    // This defaults to "shrinksafe" if not provided.
    layerOptimize: '',
--------------------------------------------------

Java 1.6.0_45
    errors: 0
    warnings: 53
    build time: 66.102 seconds

Java 1.7.0_25
    errors: 0
    warnings: 53
    build time: 51.963 seconds

Java 1.8.0-ea-b109
    errors: 0
    warnings: 53
    build time: 42.601 seconds

Node v0.10.17
    errors: 0
    warnings: 53
    build time: 8.502 seconds

--------------------------------------------------
    // This option defaults to "" (no compression) if not provided.
    optimize: 'shrinksafe',
    // This defaults to "shrinksafe" if not provided.
    layerOptimize: '',
--------------------------------------------------

Java 1.6.0_45
    errors: 0
    warnings: 53
    build time: 67.351 seconds

Java 1.7.0_25
    errors: 0
    warnings: 53
    build time: 56.732 seconds

Java 1.8.0-ea-b109
    errors: 0
    warnings: 53
    build time: 43.933 seconds

Node v0.10.17
    errors: 0
    warnings: 53
    build time: 10.477 seconds

  • 28 March 2014
  • 26 October 2014 - Added JDK 1.8.0_25 and Node 0.10.32

Could this have something to do with the Node builds taking much longer time for 1.9.x and above? https://bugs.dojotoolkit.org/ticket/17105

Dojo    Optimiser   Node     Java        Time

1.10.2  closure     N        1.8.0_25    21.649
1.10.2  closure     N        1.6.0_45    28.892
1.10.2  closure     0.10.32  1.8.0_25    93.472
1.10.2  closure     0.10.32  1.6.0_45    68.851

1.9.5   closure     N        1.8.0_25    26.113

1.9.3   closure     N        1.8.0_25    25.31
1.9.3   closure     N        1.8.0       53.322
1.9.3   closure     N        1.7.0_51    65.758
1.9.3   closure     0.10.26  1.7.0_51    105.725
1.9.3   closure     0.10.26  1.8.0       103.879

1.8.6   closure     N        1.7.0_51    84.862    67.128(mc)
1.8.6   closure     N        1.8.0       73.492    55.663(mc)
1.8.6   closure     N        1.8.0_25    23.408

1.8.6   closure     0.10.26  1.7.0_51    45.756
1.8.6   closure     0.10.26  1.8.0       45.473
1.8.6   closure     0.10.32  1.8.0_25    36.572

1.10.2  NONE        N        1.8.0_25    10.605
1.10.2  NONE        N        1.6.0_45    18.145
1.10.2  NONE        0.10.32  1.8.0_25    3.067

1.10.2  shrinksafe  N        1.8.0_25    12.605
1.10.2  shrinksafe  0.10.32  1.8.0_25    13.444
1.10.2  shrinksafe  N        1.6.0_45    20.09

1.10.4  NONE        0.12.4   n/a         

* (mc == minimised console. some runs print a lot of info to the console, and it is faster if the console is minimised)
JDK 1.7.0_51   Java(TM) SE Runtime Environment (build 1.7.0_51-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
JDK 1.8.0      Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)
JDK 1.8.0_25   Java(TM) SE Runtime Environment (build 1.8.0_25-b18) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

05/07/2015

Command line (from Git Bash):

For node - ./src/util/buildscripts/build.sh --profile profiles/app.profile.js --releaseDir ../dist > /dev/null

For Java - ./src/util/buildscripts/build.sh --bin java --profile profiles/app.profile.js --releaseDir ../dist > /dev/null

Env

  • Ugly = uglify-js
  • L-Optimiser = layerOptimize setting in app.profile.js
java version "1.8.0_45"  Java(TM) SE Runtime Environment (build 1.8.0_45-b15)  Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
java version "1.7.0_71"  Java(TM) SE Runtime Environment (build 1.7.0_71-b14)  Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)

Results

Dojo    Optimiser   L-Optimiser Node     Java        Time

1.10.4  NONE        NONE        0.12.4   N           13.155
1.10.4  NONE        NONE        N        1.8.0_45    32.29
1.10.4  NONE        NONE        N        1.7.0_71    34.577

1.10.4  ugly@2.4.23 NONE        0.12.4   N           51.186
1.10.4  closure     NONE        N        1.8.0_45    58.377

1.10.4  NONE        ugly@2.4.23 0.12.4   N           14.293
1.10.4  NONE        closure     N        1.8.0_45    37.235
1.10.4  NONE        closure     N        1.7.0_71    40.279

CSS selector limit.

KB 262161 outlines the maximum number of stylesheets and rules supported by Internet Explorer 6 to 9.

A sheet may contain up to 4095 rules A sheet may @import up to 31 sheets @import nesting supports up to 4 levels deep


Quick code to try and parse the selectors out of CSS. Paste into a console and use selectors = GRIMBO.getSelectors(GRIMBO.getSource()).

GRIMBO = (function() {
// get the source out of chrome, which wraps <pre> tags around the body if browsing directly to a CSS file
function getSource() {
    var s = document.body.innerHTML;
    s = s.substring(s.indexOf('>') + 1, s.lastIndexOf('<'));
    return s;
}

// split on comma
function splitSelectors(selectors) {
    return selectors.split(/,/);
}

// find curly braces, and turn that into the selector list and the rules
function getSelectors(css) {
    var r, re = /([^{]*){([^}]*)}/g,
        arr = [];
    while (r = re.exec(css)) {
        var selectors = r[1];
        var rules = r[2];
        splitSelectors(selectors).forEach(function(selector) {
            arr.push([selector, rules]);
        });
    }
    return {
        css: css,
        selectors: arr
    };
}

return {
    getSource: getSource,
    getSelectors: getSelectors
}
}());

Using node/rhino fs module instead of using Windows cmd /c copy.

One build (with Dojo, Dijit, Dojox and some app code gives these results)*:

  • modified - 12.792s
  • original - 48.729s

*the laptop running the test has overbearing anti-virus checking (PrivilegeGuardService.exe and mcshield.exe), so lots of I/O is penalised by the AV.

define([
	"../buildControl",
	"../process",
	"../fileUtils",
	"../fs",
	"dojo/has"
], function(bc, process, fileUtils, utilFs, has) {

	var nodeFs = has("host-node") ? require.nodeRequire("fs") : null;

	//http://stackoverflow.com/a/14387791/319878
	function copyFileWithNodeFs(source, target, cb) {
		var fs = nodeFs;
		var cbCalled = false;

		var rd = fs.createReadStream(source);
		rd.on("error", function(err) {
			done(err);
		});
		var wr = fs.createWriteStream(target);
		wr.on("error", function(err) {
			done(err);
		});
		wr.on("close", function(ex) {
			done();
		});
		rd.pipe(wr);

		function done(err) {
			if (!cbCalled) {
				cb(err);
				cbCalled = true;
			}
		}
	}

	function copyFileWithUtilFs(src, dest, cb) {
		var fs = utilFs;
		if (has("is-windows")) {
			src = fileUtils.normalize(src);
			dest = fileUtils.normalize(dest);
		}
		fs.readFile(src, "utf8", function(err, contents) {
			if (err) {
				cb(err);
			} else {
				fs.writeFile(dest, contents, "utf8", cb);
			}
		});
	}

	return function(resource, callback) {
		fileUtils.ensureDirectoryByFilename(resource.dest);
		var
			cb = function(code, text){
				callback(resource, code);
			},
			errorMessage = "failed to copy file from \"" + resource.src + "\" to \"" + resource.dest + "\"",
			args = has("is-windows") ?
				["cmd", "/c", "copy", fileUtils.normalize(resource.src), fileUtils.normalize(resource.dest), errorMessage, bc, cb] :
				["cp", resource.src, resource.dest, errorMessage, bc, cb];

		//grimbo
		if (nodeFs && bc.useNodeFsCopy) {
			copyFileWithNodeFs(resource.src, resource.dest, cb);
			return callback;
		} else if (utilFs && bc.useUtilFsCopy) {
			copyFileWithUtilFs(resource.src, resource.dest, cb);
			return callback;
		}

		process.exec.apply(process, args);
		return callback;
	};
});

If the build hangs, it could be a filepath issue:

http://stackoverflow.com/questions/11148947/dojo-1-7-build-out-of-memory-errors

Finally found the problem, the releaseDir switch value had both windows and unix file separators in it. That used to work fine in >Dojo < 1.6 and typically Java has no problem with it. For some reason, the Dojo 1.7 build system hits memory problems in that case.

The releaseDir, after resolving the ant tokens from the question, had a mix of both unix and windows file separators:

So fix by using only unix file separators.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.