Comparing r215126 with r215394 I've found the following performance regression into microbenchmarks. Need to investigate the reason. baseline changes freeze-and-do-work 17.8163+-1.1731 ! 481.5174+-10.8908 ! definitely 27.0268x slower seal-and-do-work 18.0572+-1.2018 ! 491.9421+-18.0567 ! definitely 27.2436x slower <geometric> 17.9014+-0.9676 ! 486.4490+-11.4703 ! definitely 27.1737x slower
This is like change set r215272 <https://trac.webkit.org/changeset/215272>. I'll take a look at it.
<rdar://problem/31649374>
Created attachment 307319 [details] Patch
Comment on attachment 307319 [details] Patch r=me
Comment on attachment 307319 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=307319&action=review > Source/JavaScriptCore/runtime/ObjectConstructor.cpp:614 > + if (isJSFinalObject(object) && !hasIndexedProperties(object->indexingType())) { > + object->seal(vm); > + return JSValue::encode(obj); > + } In r215272 <https://trac.webkit.org/changeset/215272>, you also eliminated the fast paths for objectConstructorIsSealed() and objectConstructorIsFrozen(). Should those be restored as well with the additional !hasIndexedProperties() check?
(In reply to Mark Lam from comment #5) > Comment on attachment 307319 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=307319&action=review > > > Source/JavaScriptCore/runtime/ObjectConstructor.cpp:614 > > + if (isJSFinalObject(object) && !hasIndexedProperties(object->indexingType())) { > > + object->seal(vm); > > + return JSValue::encode(obj); > > + } > > In r215272 <https://trac.webkit.org/changeset/215272>, you also eliminated > the fast paths for objectConstructorIsSealed() and > objectConstructorIsFrozen(). Should those be restored as well with the > additional !hasIndexedProperties() check? Yes. I added those checks back in.
Committed r215471: <http://trac.webkit.org/changeset/215471>