Initial polymer_expressions benchmarks

Initial polymer_expressions benchmarks

BUG=
R=jmesserly@google.com

Committed: https://code.google.com/p/dart/source/detail?r=30320

[justinfagnani, 2013-11-15 22:08:53]

We probably want more expressions in the eval benchmark, particularly observable
values and filters. Other important cases?

Also, should we add multiple benchmarks for different cases: simple paths, index
operator, method calls, binary ops, etc.?

[Jennifer Messerly, 2013-11-15 22:32:58]

lgtm

https://codereview.chromium.org/73523004/diff/1/pkg/polymer_expressions/bench...
File pkg/polymer_expressions/benchmark/eval.dart (right):

https://codereview.chromium.org/73523004/diff/1/pkg/polymer_expressions/bench...
pkg/polymer_expressions/benchmark/eval.dart:27: final expr =
parse('foo.bar.baz');
just a rough sense based on what I've seen in code ... the most frequent types
of exprs are:

* single name -- {{foo}}
* simple path -- {{foo.bar.baz}}
* negation -- {{!foo.bar.baz}}
* (in)equality -- {{foo.bar == baz.quux}}
* simple iteration -- {{foo in foos}}
* simple iteration path -- {{bar in foo.bars}}
* iteration w/ index -- {{foo in foos | enumerate }}
* lookup name against iteration context, e.g. {{foo}} below {{foo in foos}}
* map indexing {{foo['bar']}}

then consider the following cases:
* part of the expr is null
* part of the expr is not found
* expr is fully valid

[Jennifer Messerly, 2013-11-15 22:33:43]

On 2013/11/15 22:32:58, John Messerly wrote:
> just a rough sense based on what I've seen in code ... the most frequent types
> of exprs are:
>  <snip>
> * negation -- {{!foo.bar.baz}}
> * (in)equality -- {{foo.bar == baz.quux}}

also the other logical ops -- && and ||

[justinfagnani, 2013-11-15 22:44:36]

Committed patchset #1 manually as r30320 (presubmit successful).