Blog

Escribir una extensión para cualquier aplicación que lo soporte suele ser tan complicado como detallada sea la documentación que ofrece. En el caso que nos ocupa, Google Chrome, la documentación es bastante completa aunque haya que navegar por distintos negociados de la web de desarrolladores de Chrome para encontrar todas las piezas. Y una de las partes difíciles de encontrar es cómo depurar nuestra extensión. Usando como base la que se encuentra aquí vamos a entender un poco mejor como funcionan las extensiones para Google Chrome. (more…)

Esta entrada ha estado macerando en el disco duro durante un buen tiempo. Cubre un tema que no me gusta y que me convierte, a mis tiernos ojos, en algo que tampoco me gusta: un censurador. La excusa, nosotros contra ellos.

Ellos son, esta vez, las empresas. Centrémonos en una empresa periodística. Transparente en casi todos sus aspectos. Con buen contenido, casi siempre. Esos “casis” aparecen por todas partes, en todos los aspectos de nuestras vidas. Pero esta empresa concreta se metió en un jardín: hazte socio y no verás publicidad. Casi. En su afán por conseguir contenido han perdido el control sobre lo que publican. O esa es la impresión que dan. (more…)

Sometimes we tend to over-engineer our code. Just because we think it will look smarter, or run faster, or be more canon-compliant. Let’s take, for example, this function that gets a value from the server and translates it into a class name to apply to an element.

angular.module('widgetTransactionsFilters', [])
       .filter('transactionType', function() {
	return function(input) {
		var strClass = 'type-0';

		switch(input) {
			case 'Payment Credit Card':
				strClass = 'type-1';
				break;
			case 'Cash Withdrawl':
				strClass = 'type-2';
				break;
			case 'Bill Payment':
				strClass = 'type-3';
				break;
			case 'Salary':
				strClass = 'type-4';
				break;
			case 'Online Transfer':
				strClass = 'type-5';
				break;
		}
		return strClass;
	};
});

it’s not the most elegant filter, but hey, it’s mine! As they say, devil will find code for idle hands to refactor. In this case, I decided, don’t ask me why, to change the switch for an array lookup. To make it less legible, mainly. To make any changes to the filter slightly difficult? Who knows. In any case, this was the second version.

angular.module('widgetTransactionsFilters', [])
       .filter('transactionType', function() {
	return function(input) {	
		return 'type-' + 
				(['Payment Credit Card',
				'Cash Withdrawl',
				'Bill Payment',
				'Salary',
				'Online Transfer'].indexOf(input) + 1);
	};
});

Despite my feeble attempts at AngularJS I know some things about JS. One of these things is that most of the array methods are not very optimized. So maybe it’s time to check which version is faster. Or less slow. Fortunately there’s an online tool that can help us to quickly solve this questions: jsperf.com.

Using jsperf.com. you can create a set of tests that will be run in a loop for some time. The speed of the test will be determined by the number of loops executed in that time. Additionally you can run the same tests using different browsers in different platforms. This is specially useful when you’re optimizing your code for an hybrid app where you know the browser and the platform.

You can code your setup, and add a number of tests. This is the setup:

<script>
  Benchmark.prototype.setup = function() {
    function bySwitch(input) {
        var strClass = 'type-0';
    
        switch(input) {
                case 'Payment Credit Card':
                        strClass = 'type-1';
                        break;
                case 'Cash Withdrawal':
                        strClass = 'type-2';
                        break;
                case 'Bill Payment':
                        strClass = 'type-3';
                        break;
                case 'Salary':
                        strClass = 'type-4';
                        break;
                case 'Online Transfer':
                        strClass = 'type-5';
                        break;
        }
        return strClass;
    }
    
    function byArray(input) {   
        return 'type-' + 
                        (['Payment Credit Card',
                        'Cash Withdrawal',
                        'Bill Payment',
                        'Salary',
                        'Online Transfer'].indexOf(input) + 1);
    }
  };
</script>

And these are the tests, along with the results.

As you can see, the array lookup is way more slow than the old fashioned switch. Not surprises here, people. The only surprise can be the huge difference of performance between Chrome Canary and WebKit when you perform the same test in both browsers.

Corollary: be careful when you start refactoring and always test the performance of your code.

UPDATE: Vyacheslav Egorov, aka @mraleph, noticed this post and thankfully redirected me to this excellent presentation on how to avoid benchmarking pitfalls due to the JIT optimization. Basically “optimizer eats µbenchmarks for breakfast”.

I’ve modified the first function to force the switch input NOT to be treated by the compiler as a constant, by changing it from switch(input) to switch(input.toString()). And here are the updated results.

The difference is still there, both between browsers and ways to test for the string. But the number of iterations for each test shows that all (or most) of the code in each of my tests is being executed. Or so I hope. BTW, the benchmark is located here. Feel free to use and abuse it.

So, the bottom line is: 1. don’t trust blindly in microbenchmarks, 2. don’t assume anything about the language and 3. run, don’t walk, to see mraleph’s presentation.