Bug 116764 – CompareEq should be a DCE candidate

• Component: JavaScriptCore
• Status: NEW

[Joseph Pecoraro]

I stumbled across a micro-benchmark today comparing == and === between strings. Chrome and Firefox have nearly equivalent performance for each, while the WebKit Nightly showed `===` being noticeably better than `==`. It seems we could improve `==` in such cases to match `===`:
<http://jsperf.com/comparison-of-comparisons>

WebKit Nightly r150579 / Safari 6.0.4:
==: 260,969,330
===: 420,311,703
difference: ~61% more

Chrome Canary 29.0.1518.2:
==: 367,785,800
===: 375,298,004
difference: ~2% more

Firefox Nightly 23.0a1 (2013-04-28):
==: 776,644,421
===: 777,027,376
difference: ~0% more


JSBench Test

Setup:
<script>
  Benchmark.prototype.setup = function() {
    var a = 'hello';
    var b = 'world';
    var c = 'hello';
  };
</script>

Test1: "Identity"
a === b;
a === c;

Test2: "Equality"
a == b;
a == c;

[Radar WebKit Bug Importer]

<rdar://problem/13990643>

[Joseph Pecoraro]

This may be a better test page, it tests a broader range of string `==` and `===` comparisons:
<http://jsperf.com/simple-string-comparisons>

[Filip Pizlo]

(In reply to comment #0)
> I stumbled across a micro-benchmark today comparing == and === between strings. Chrome and Firefox have nearly equivalent performance for each, while the WebKit Nightly showed `===` being noticeably better than `==`. It seems we could improve `==` in such cases to match `===`:
> <http://jsperf.com/comparison-of-comparisons>
> 
> WebKit Nightly r150579 / Safari 6.0.4:
> ==: 260,969,330
> ===: 420,311,703
> difference: ~61% more
> 
> Chrome Canary 29.0.1518.2:
> ==: 367,785,800
> ===: 375,298,004
> difference: ~2% more
> 
> Firefox Nightly 23.0a1 (2013-04-28):
> ==: 776,644,421
> ===: 777,027,376
> difference: ~0% more
> 
> 
> JSBench Test
> 
> Setup:
> <script>
>   Benchmark.prototype.setup = function() {
>     var a = 'hello';
>     var b = 'world';
>     var c = 'hello';
>   };
> </script>
> 
> Test1: "Identity"
> a === b;
> a === c;
> 
> Test2: "Equality"
> a == b;
> a == c;

Lol.  This is just us being dumb.  We have separate implementations of == and === and we added more optimizations to one and not the other, I guess.

[Filip Pizlo]

(In reply to comment #3)
> (In reply to comment #0)
> > I stumbled across a micro-benchmark today comparing == and === between strings. Chrome and Firefox have nearly equivalent performance for each, while the WebKit Nightly showed `===` being noticeably better than `==`. It seems we could improve `==` in such cases to match `===`:
> > <http://jsperf.com/comparison-of-comparisons>
> > 
> > WebKit Nightly r150579 / Safari 6.0.4:
> > ==: 260,969,330
> > ===: 420,311,703
> > difference: ~61% more
> > 
> > Chrome Canary 29.0.1518.2:
> > ==: 367,785,800
> > ===: 375,298,004
> > difference: ~2% more
> > 
> > Firefox Nightly 23.0a1 (2013-04-28):
> > ==: 776,644,421
> > ===: 777,027,376
> > difference: ~0% more
> > 
> > 
> > JSBench Test
> > 
> > Setup:
> > <script>
> >   Benchmark.prototype.setup = function() {
> >     var a = 'hello';
> >     var b = 'world';
> >     var c = 'hello';
> >   };
> > </script>
> > 
> > Test1: "Identity"
> > a === b;
> > a === c;
> > 
> > Test2: "Equality"
> > a == b;
> > a == c;
> 
> Lol.  This is just us being dumb.  We have separate implementations of == and === and we added more optimizations to one and not the other, I guess.

Lololololo.

Here's why.

CompareStrictEq (i.e. ===) is a DCE candidate.  So we dead-code eliminate it.

CompareEq isn't, because it could possibly be effectful.  We're being slightly more paranoid than we need to be.

In any case, it appears that this silly test that just checks if the relevant op can be dead-code eliminated, and after it is eliminated, it tests how ridiculously good of a job the VM's top tier compiler does at killing the entire test loop.