Bug 90844 – Avoid creating temporary variables when accessing the size or location in a IntRect or FloatRect object

• Component: New Bugs
• Status: RESOLVED INVALID

[Dana Jansens]

Avoid creating temporary variables when accessing the size or location in a IntRect or FloatRect object

[Dana Jansens]

Created attachment 151379 [details]
Patch

[Alexey Proskuryakov]

Comment on attachment 151379 [details]
Patch

Does this patch measurably improve performance? These functions are inline, so I don't expect this change to be an improvement. On the other hand, adding an extra deference might theoretically complicate the code enough to confuse optimizer.

[Dana Jansens]

I expect it would be difficult to measure, but these prevent other methods from also returning references, methods who themselves may not be inline. For example, this isn't possible and you must return an IntSize instead because of these methods.

const IntSize& Bar::sizeOfSomething(Foo& foo) {
  return foo.rect().size();
}

Typically things that return non-basic types always return a const reference when possible. I have a hard time believing a const reference would produce worse code than a temporary variable.

[Alexey Proskuryakov]

> I have a hard time believing a const reference would produce worse code than a temporary variable.

Remember that a reference is the same as a pointer, so unless an optimizer can eliminate such syntactic improvements, you get dereferencing of a pointer with all associated performance issues.

[Adrienne Walker]

Comment on attachment 151379 [details]
Patch

Are you sure that return value optimization is not in play here? What does the assembly look like before and after on different compilers?

[Simon Fraser (smfr)]

You could study the disassembly to see what's actually happening.

[Eric Seidel (no email)]

Comment on attachment 151379 [details]
Patch

OK.  LayoutRect?

[Eric Seidel (no email)]

Comment on attachment 151379 [details]
Patch

Yes, w/o performance numbers it's impossible to do performance changes. :)

[Dana Jansens]

Additional reading suggests this change would be a bad one. http://www.macieira.org/blog/2012/02/the-value-of-passing-by-value/

Going to close this, thanks.