Both new object creation (bug 933277) and assignments (bug 933289) can result in calls to the self-hosted helper ConvertAndCopyTo. In some cases we should be able to further optimize these calls by "unrolling" them into a series of accesses and assignments. We have to be very careful because if a jit bailout should occur it may not be observable, and there is no convenient bytecode to jump back into. Therefore I would probably write this optimization to examine the value being converted and handle two cases: 1. The value being converted is known to be a typed object of equivalent type. We can use memcpy in that case. This may be better done in IonBuilder directly. 2. TI can guarantee for us that loading the properties and converting the values we need to load/convert will not have side-effects, so it's okay for these loads/conversions to be replayed if necessary. This will frequently occur in the common case of users using literal syntax (`new Point({x: 22, y: 44})`) -- in that case we should be able to determine the precise *value* that is being loaded (22 for `x`, etc).

Some discussion of my plan here: http://smallcultfollowing.com/babysteps/blog/2013/11/04/optimizing-complex-typed-object-assignments/

Test case that performs better. I'm reluctant to add this as a jit-test, instead I'd like to setup some benchmarks in awfy (perhaps including this one).

Comment on attachment 830572 [details] [diff] [review] Bug933293.diff Attached to wrong bug (argh).

Comment on attachment 830574 [details] jaswanth.js Attached to wrong bug (argh).

Assuming p5 because related to typed objects, which are nightly-only and not specced yet.