(2014/03/29 12:27), Boris Zbarsky wrote:
On 3/28/14 6:42 PM, Neil wrote:
Boris Zbarsky wrote:
But "slow" here is a relative term. Last I measured, something like a
basic property get in Ion code went from 2-3 instructions to 20-30
instructions when we deoptimize.
...
What about calls from x
On 3/28/14 6:42 PM, Neil wrote:
Boris Zbarsky wrote:
But "slow" here is a relative term. Last I measured, something like a
basic property get in Ion code went from 2-3 instructions to 20-30
instructions when we deoptimize.
...
What about calls from xpconnect (the original object was a compon
Boris Zbarsky wrote:
On 3/28/14 2:15 PM, Gregory Szorc wrote:
I'm concerned about this as well.
Is the concern the spew, or the performance of changing __proto__?
In practice, what gets slow with a changing __proto__ is property
access on the object, because the JS engine throws away type
On 3/28/14 4:03 PM, David Rajchenbach-Teller wrote:
The prototype mutation is hardly necessary for bug 939072, it is just a
nice way to avoid a few indirections.
Note that indirection is not free in perf terms either.
But again, I doubt that the code in bug 939072 is gated on property
access
The prototype mutation is hardly necessary for bug 939072, it is just a
nice way to avoid a few indirections.
On 3/28/14 7:15 PM, Gregory Szorc wrote:
> I'm concerned about this as well.
>
> In bug 939072, we're looking at doing some dynamic prototype mutation so
> Sqlite.jsm can do things like a
On 03/28/2014 11:01 AM, Andrew Sutherland wrote:
The code should be fixed. It's my understanding that the existing idiom
used throughout the Thunderbird tree is still okay to do since the prototype
chain is created at object initialization time and so there's no actual
mutation of the chain:
fu
On 03/28/2014 02:01 PM, Andrew Sutherland wrote:
> It's my understanding that the existing idiom used throughout the Thunderbird
> tree is still okay to do since the prototype chain is created at object
> initialization time and so there's no actual mutation of the chain:
>
> function Applicatio
On 3/28/14 2:15 PM, Gregory Szorc wrote:
I'm concerned about this as well.
Is the concern the spew, or the performance of changing __proto__?
In practice, what gets slow with a changing __proto__ is property access
on the object, because the JS engine throws away type inference
information a
On 3/28/14, 10:31 AM, ISHIKAWA,chiaki wrote:
Recently after a refesh of code from comm-central,
I noticed that running |make mozmill|
TB test suite using full DEBUG BUILD of TB produced the
following warning lines:
System JS : WARNING
file:///REF-OBJ-DIR/objdir-tb3/mozilla/dist/bin/components/st
The code should be fixed. It's my understanding that the existing idiom
used throughout the Thunderbird tree is still okay to do since the
prototype chain is created at object initialization time and so there's
no actual mutation of the chain:
function Application() {
}
Application.prototype
Recently after a refesh of code from comm-central,
I noticed that running |make mozmill|
TB test suite using full DEBUG BUILD of TB produced the
following warning lines:
System JS : WARNING
file:///REF-OBJ-DIR/objdir-tb3/mozilla/dist/bin/components/steelApplication.js:783
- mutating the [[Prototyp
11 matches
Mail list logo
