Inline gfx::Vector2d* ctors and integer conversions

Inline gfx::Vector2d* ctors and integer conversions

This speeds up cc_perftests by 2.85%. 0.7% is from the vector constructors, the
remainder is from inlining the safe_integer_conversion routines.

BUG=


Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=170775

[jamesr, 2012-12-01 07:19:58]

More of the same, but a decent enough improvement to be worth it on my mac.

Interestingly the safe_integer_conversion routines are still really hot - if we
could skip them completely it'd buy us another 1.3% but I doubt we can do that.

[danakj, 2012-12-01 19:07:46]

LGTM

How about Vector3dF?

[danakj, 2012-12-01 19:09:11]

On 2012/12/01 19:07:46, danakj wrote:
> LGTM
> 
> How about Vector3dF?

Also, worth trying ToEnclosing/EnclosedRect? If the integer conversions are so
hot, I'd expect it to be because of those.

[jamesr, 2012-12-01 19:44:41]

On 2012/12/01 19:09:11, danakj wrote:
> On 2012/12/01 19:07:46, danakj wrote:
> > LGTM
> > 
> > How about Vector3dF?

We don't use Vector3dF in the compositor at all except for the layer sorter and
don't have a benchmark for layer sorting performance.  Most of our math either
uses 2d vectors or homogeneous (4d).  I suspect it probably would benefit from
inlining as well, but would prefer to make that decision with data.  It might
turn out to not matter given the way the layer sorter works.

Do you know of any other code that's heavy on vector3df?
> 
> Also, worth trying ToEnclosing/EnclosedRect? If the integer conversions are so
> hot, I'd expect it to be because of those.

Tried it - but inlining doesn't seem to speed things up.  These functions are
pretty long so I don't think the function call overhead is worth the code bloat.

[danakj, 2012-12-01 20:00:18]

On 2012/12/01 19:44:41, jamesr wrote:
> On 2012/12/01 19:09:11, danakj wrote:
> > On 2012/12/01 19:07:46, danakj wrote:
> > > LGTM
> > > 
> > > How about Vector3dF?
> 
> We don't use Vector3dF in the compositor at all except for the layer sorter
and
> don't have a benchmark for layer sorting performance.  Most of our math either
> uses 2d vectors or homogeneous (4d).  I suspect it probably would benefit from
> inlining as well, but would prefer to make that decision with data.  It might
> turn out to not matter given the way the layer sorter works.

Ya, that sgtm. I'll try remember that we need a perf test with preserves 3d in
it!

> Do you know of any other code that's heavy on vector3df?

Animation code makes use of it, I believe for interpolating. But IIRC it's all
moving to double math with custom inlined stuff now anyhow.

We were going to use it a bunch in matrix RotateAbout, but we dodged that with
common cases covered by RotateAboutXAxis() etc methods.

I guess at some point we'll probably start making use of it more for something,
and we can notice the function get hot in profiling at that time. Then again,
for constructors it seems a simple change, and might be worth doing
preemptively. I guess I don't mind either way really since it doesn't change
much for us now.

> > Also, worth trying ToEnclosing/EnclosedRect? If the integer conversions are
so
> > hot, I'd expect it to be because of those.
> 
> Tried it - but inlining doesn't seem to speed things up.  These functions are
> pretty long so I don't think the function call overhead is worth the code
bloat.

Ok cool, glad you tried it!

[sky, 2012-12-03 15:45:39]

LGTM

[commit-bot: I haz the power, 2012-12-03 17:37:37]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jamesr@chromium.org/11414284/6002

[commit-bot: I haz the power, 2012-12-03 18:51:29]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jamesr@chromium.org/11414284/6002

[commit-bot: I haz the power, 2012-12-03 19:04:11]

Change committed as 170775