A working test case attached below.
Also observed in Firefox.

The string key speed was just as slow before r142179 V8 roll landed in Chrome 21.0.1175.0:
https://chromium.googlesource.com/v8/v8/+log/052b24ac..06e015b4?pretty=fuller

Deleted: test.html 1.6 KB

test.html 1.6 KB View Download

wojciech.danilo@ Thanks for the issue.

Able to reproduce this issue on Mac OS 10.13.6,Windows 10 and Ubuntu 17.10 on the latest Stable 70.0.3538.110 and latest Canary 73.0.3629.0 as per comment #1.
This is a Non-Regression issue as this behavior is observed from M-60 chrome builds.
Attached is the screen shot for reference.

Hence marking this as Untriaged for further updates from Dev.

Thanks..

Deleted: 908743-M60.PNG 49.9 KB

	908743-M60.PNG 49.9 KB View Download

"This is a Non-Regression issue as this behavior is observed from M-60 chrome builds."

https://jsperf.com/es5-getters-setters-versus-getter-setter-methods/18 history suggests
that it _is_ a regression. Between M48 and M57 performance dropped by an order of magnitude.
The latest revision of this benchmark was on 2016-2-8, by which time M48 already existed.

Hope this may be helpful in tracking down the cause of the issue.

re 6, using the same test.html bisected to https://chromium.googlesource.com/v8/v8/+log/98d2ed87..aaf1b5c3
Suspecting 4c41d007d932ed6eba7514f2d4e44def61cd5fb8 = crrev.com/1697153002
Landed in 50.0.2652.0 via r375485

cc Toon re. bisect in #7

Note, #6-#7 is probably a sub-issue about the string name getter slowdown in Chrome 50 whereas the initial report is about a numeric name getter being slow, which was that way since at least Chrome 5 where Object.defineProperty was added.

I don't think that CL has anything to do with this since that's about speeding up adding *data* properties.

I think you're interpreting JSPerf wrongly; as is often the case with microbenchmarks through a complex runner like jsperf. I presume that something with the runner possibly in combination with the optimizing compiler is now not kicking in in a way that seems fast on the resulting graph. E.g., if you run the following without JSPerf:

function test() {
   var obj = {
   _prop: 0,
   get prop() {
    return this._prop;
   },
   set prop(value) {
    this._prop = value;
   },
   getProp: function() {
    return this._prop;
   },
   setProp: function(value) {
    this._prop = value;
   }
  };
  var a = 0;

  var s1 = Date.now();
  for (let i = 0; i < 100000000; i++) {
    a += obj.prop;
  }
  print(Date.now() - s1);

  a = 0;
  var s2 = Date.now();
  for (let i = 0; i < 100000000; i++) {
    a += obj.prop;
  }
  print(Date.now() - s2);
}

test();

You get roughly the same results for both (slightly slower for the second, but that's just due to other side effects, and not because getters are actually slower).

Numeric getters have never been inlined in the optimizing compiler since non-default-data-properties always cause the object to go in dictionary mode. At that point we lose all guarantees and the optimizing compiler can't do anything but  access the property through dynamic lookup, whereas the data properties are simple array accesses. Even inline caches have worse performance because they need to do a dictionary lookup.

As mentioned by others before, this is working as it always has.

re 10, I can confirm this. Although, I had to change `print` to `console.log`, as the former literally brings up the print dialog :) I get 1983ms and 2005ms, respectively in Chrome 71.0.3578.98 and about the same performance in Safari. But it only takes 61ms and 60ms in Firefox 64.0.2, even if I change the value of `_prop` from zero to some other number and console.log the resulting sum (which is correct). Probably some other optimization on their part, not related to getter performance, but still noteworthy, I think.