phpnode

This seems rather odd from example 14:

    // Boolean expressions need to resolve to either true or false, as no
    // implicit conversions are supported.

I'm sure they have good reason for this, does anyone know of the rationale? I think I'd miss patterns like `if (arr.length) { ... }`

I couldn't get this to work, after selecting a song it appears to work for ~30 seconds and replies with "This song cannot be analyzed because it is not set as public on YouTube." or "This song cannot be analyzed because it is not set as public on SoundCloud."

from the top of my head:

UK, USA, Canada, Australia, New Zealand, Netherlands, Germany, Austria, all of Scandinavia

60 bucks is less than an hour's pay for many developers. We're talking about a tool that gets used for > 8hrs/day in many cases. Other industries would DREAM of having tools this cheap!

* edited to remove the word "most" which seems to be upsetting some people.

This looks cool but I think your syntax clashes with JS's standard LabeledStatement

Most of the comments on that article are really depressing, ill considered mumblings from armchair programmers.

The solution is not at all straightforward, this whole thing has been a game between blackhat SEOs and google for many years. The spammers make a move, google makes a move, spammers respond ad infinitum.

The problem is that spammers / extortionists can adapt their techniques much more so than Google can.

They care solely about getting paid, they don't care about building a brand, offering a good service or anything else. This allows them a huge degree of flexibility when finding ways to attack their less nimble adversary. They can transition from selling viagra to extortion with ease.

If it was straightforward, a company which employs many of the most gifted, technical minds in the world should probably have figured it out by now. Also, it's very unlikely that Pagerank is even in use at all at this point.

sure, it's just that the open bar is funded by the "lucky" player

this jsperf revision is slightly more interesting to me http://jsperf.com/json-vs-transit/3

it's effectively the same input, but optimised for JSON.parse() rather than transit. This means it purely decodes into objects with fast properties (in V8 at least), so objects never have to undergo the -> hash table transition. It seems consistently faster, but you can argue that it's not doing quite the same thing.

It's trivial to do an experiment yourself, copy a load of text from a wikipedia article into a text file then open it in your browser, full screen. Depending on your display size you'll probably find it hard to read when line width exceeds roughly 90 chars

the issue is that the tobacco companies knew that their product is both addictive and deadly, but they did not warn their customers of either of these aspects. The fact that cigarettes are widely known to be harmful is immaterial. If you sell a product that is going to kill the end user, you should warn them.

R3 does look fast, but there's a cost to crossing the JS -> C barrier. It's almost certainly possible to beat it using the same algorithm written in pure JS.

(5).amIFive();

Agreed, I'm European and I've never seen a refrigerated egg in my life.

I quite like this suggestion. If we flip the key, value around to make it inline with what forEach etc do, then we don't need the placeholder for iterating without the key:

    fast-each [value] from arr {

    }

    fast-each {value} from obj {

    }
 
    fast-each [value, key] from arr {

    }

    fast-each {value, key} from obj {

    }

The disadvantage is that this looks like array comprehension but isn't.

Alternative:

    fast-properties key, value from obj {

    }

    fast-elements index, value from arr {

    }

    fast-properties value from obj {

    }

    fast-elements value from arr {

    }

There's something going on with the perf tests - most of that code is being optimised away, in one case I got over a billion cycles per second. The trick to these things is writing code which cannot be optimised away, like returning Math.random() from a function and using the return value to increment another variable.

the other benefit is that `void 0` cannot be overwritten in sloppy mode, whereas you can do something crazy like this:

    undefined = 'lol';

The issue with coffeescript is that it uses the opposite syntax to JS - `in` for arrays instead of objects. ES6 introduces the `of` keyword for real iterators so i don't really want to use that for either of them. It's tricky. There are other options but they're verbose

    every element as key, value from arr {
      console.log(key, value);
    }

    every property as key, value from obj {
      console.log(key, value);
    }

The article is "optimisation killers", you're right about caching the array length lookup check being faster, but it doesn't kill V8's ability to optimise functions like the rest of the examples do

`for ... in` is a relatively slow construct anyway, the faster option (a lot more verbose) is:

    var keys = Object.keys(obj),
        length = keys.length,
        key, i;
    for (i = 0; i < length; i++) {
      key = keys[i];
    }

While this is not exactly the same as for..in, it usually behaves how you'd expect and is significantly faster for a couple of reasons:

1. In a for..in loop the engine must keep track of the keys already iterated over, whereas in the fast version we can simply increment a counter and do a fast array lookup.

2. It's possible to add properties to the object that you're iterating within the body of the for..in statement, and these will be iterated too. Doing such a thing is obviously very rare but it's the kind of edge case the JS engine must keep track of.

the only issue is i'd like to differentiate between iterating arrays and objects at the syntax level. Coffeescript uses `in` for arrays and `of` for objects, but I agree that becomes confusing. Open to other suggestions!

it's not that kind of edge case. It simply means that some very uncommon constructs are not supported. If you never use those constructs, which basically nobody does, then it will never fail. (and in fact the failure mode is pretty soft and unlikely to crash your application). If your code worked with this once, it will always work.

sparse arrays are just one edge case that the native implementation must consider, see this comment - https://github.com/angular/angular.js/issues/6697#issuecomme...

Thanks again for this, this evening I'll investigate why lodash beats fast.js on some of the iteration functions (although they're close)

thanks for this! it looks like there's some room for improvement in the .map / .forEach implementations but the rest seems to stack up pretty well.

no, but I could probably have worded it better. What I mean to say is that if you do this in JS:

   function add (a, b) {
     return a + b;
   }

and this in C:

  int add(int a,int b)
  {       
     return a + b;
  }

you're going to get essentially the same performance.

The latter sentence you quoted refers to the specific builtin functions that fast.js re-implements. So we first get close to native performance in JS, then we beat the builtin functions by doing less work overall.

regarding your edit, you're exactly right, of course a for loop will be faster. Sometimes you really do need a function call though, in which case fast forEach and map implementations become more useful.

The next step for fast.js are some sweet.js macros which will make writing for loops a bit nicer, because it's pretty painful to write this every time you want to iterate over an object:

    var keys = Object.keys(obj),
        length = keys.length,
        key, i;
    for (i = 0; i < length; i++) {
      key = keys[i];
      // ...
    }

I'd rather write:

   every key of obj {
     // ...
   }

and have that expanded at compile time.

Additionally there are some cases where you must use inline for loops (such as when slicing arguments objects, see https://github.com/petkaantonov/bluebird/wiki/Optimization-k...) and a function call is not possible. These can also be addressed with sweet.js macros.

if you've ever written a for loop like this, you'd see the exact same issue.

    for (i = 0, total = arr.length; i < total; i++) {
      item = arr[i];
    }

This will also iterate over gaps in the array. Is this a bug?

This is actually unlikely to be a problem. The edge cases ignored here are actually the same as those ignored by underscore.js, which is obviously a very popular library.