Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vector2.clone() performance hit for x86-64 and ARM64? [MOVED] #55542

Open
JosefWN opened this issue Apr 22, 2024 · 4 comments
Open

Vector2.clone() performance hit for x86-64 and ARM64? [MOVED] #55542

JosefWN opened this issue Apr 22, 2024 · 4 comments
Labels
area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. P3 A lower priority bug or feature request triaged Issue has been triaged by sub team type-performance Issue relates to performance or code size

Comments

@JosefWN
Copy link

JosefWN commented Apr 22, 2024

Hello! I'm experiencing a pretty heavy performance hit with Vector2.clone() on ARM64 (M3) and x86-64 in Dart 3.3.3 on macOS/Windows. This is a continuation of google/vector_math.dart#319, which was misplaced.

Example benchmark:

class Vector2CloneBenchmark extends BenchmarkBase {
  const Vector2CloneBenchmark() : super('CloneVector2');

  @override
  void run() {
    for (double i = -500; i <= 500; i += 0.75) {
      for (double j = -500; j <= 500; j += 0.75) {
        final _ = Vector2(j, i).clone();
      }
    }
  }
}

AOT:

CloneVector2(RunTime): 135596.2 us.

For comparison, the same benchmark loop with a custom PointDouble(i, j) + PointDouble(j, i) completes in 9000 us. Only creating and cloning a Vector2 is 15-20x slower than creating two PointDouble and adding them to form a third.

It could be completely unrelated, but the other day I observed another heavy performance hit for the double implementation of i.remainder(j) which seems to occur across different platforms: #55479.

@mraleph
Copy link
Member

mraleph commented Apr 24, 2024

AOT compiler is rather conservative with its inlining heuristics (for code size reasons) and does not always correctly inline even profitable methods.

I would recommend that package:vector_math plasters @pragma('vm:prefer-inline') all over its APIs as a workaround.

I don't know if we can fix something short term here. /cc @alexmarkov

@mraleph
Copy link
Member

mraleph commented Apr 24, 2024

/cc @johnmccutchan for visibility

@mraleph mraleph added area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. type-performance Issue relates to performance or code size labels Apr 24, 2024
@johnmccutchan
Copy link
Contributor

Thanks for the @pragma('vm:prefer-inline') tip @mraleph

@a-siva a-siva added P3 A lower priority bug or feature request triaged Issue has been triaged by sub team labels Apr 24, 2024
@a-siva
Copy link
Contributor

a-siva commented Apr 24, 2024

Hopefully @pragma('vm:prefer-inline') helps to certain extent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. P3 A lower priority bug or feature request triaged Issue has been triaged by sub team type-performance Issue relates to performance or code size
Projects
None yet
Development

No branches or pull requests

4 participants