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

Slow linear scan when instantiating types / unlimited size type instantiation cache #48344

Closed
mkustermann opened this issue Feb 8, 2022 · 0 comments
Assignees
Labels
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

Comments

@mkustermann
Copy link
Member

mkustermann commented Feb 8, 2022

Right now we have a linear cache stored on uninstantiated TypeArguments objects that is consulted when code wants to instantiate it with instance/function type arguments vectors. The linear cache doesn't have a limit, see TypeArguments::InstantiateAndCanonicalizeFrom

For most classes this is not a problem due to the limited number of actual instantiated TAVs.

Though for some classes that are instantiated with many different types, this linear search can become a performance issue. One issue identified is in our Future implementation:

class _FutureListener<S, T> { }

class _Future<T> {
  FutureOr<T> handleValue(S sourceResult) {
    return _zone.runUnary<FutureOr<T>, S>(_onValue, sourceResult);
  }
}

There can be many different values for T and S (~ as many different return types there are for async functions). This can cause significant slowdown of larger apps.

Though this is of course not limited to Future related code - it's an issue for any class that is used with many different types. I imagine HashMap suffering from the same, which uses

class _HashMap<K, V>  {
  void _addEntry(...) {
    buckets[index] = new _HashMapEntry<K, V>(...)
}
@mkustermann mkustermann 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 Feb 8, 2022
copybara-service bot pushed a commit that referenced this issue Nov 28, 2022
TEST=ci

Bug: #48344
Change-Id: I7c0cee827a09d981e6e65802304a361ace7ce501
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-dwarf-linux-product-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-nnbd-mac-release-arm64-try,vm-kernel-precomp-nnbd-linux-release-simarm_x64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-nnbd-linux-release-x64-try,vm-kernel-precomp-nnbd-linux-release-simarm64-try,vm-kernel-precomp-nnbd-linux-debug-simriscv64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/270102
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
copybara-service bot pushed a commit that referenced this issue Nov 28, 2022
Previously, the VM used a linear array to cache previous instantiations
of a type arguments object. Now once the cache hits a certain number
of occupied entries, the VM changes to using a hash-based approach.

The InstantiateTypeArguments stubs have not yet been updated to
traverse the hash-based cache, so once the cache has grown too large,
all attempts at instantiations, even those that are in the cache, go to
the runtime. Thus, until the stubs are updated, this is only an
improvement if the cost of traversing the linear cache dominates the
cost of making a runtime call. Our benchmarks see a ~40% performance
regression for hash-based caches of size 100 but a ~400% performance
improvement for hash-based caches of size 1000. Thus, we currently
split the difference and set the maximum size of linear caches to 500.

TEST=vm/cc/TypeArguments_Cache_ManyInstantiations

Bug: #48344
Change-Id: I7f1376943523bb5bcd8b175cfb1936779ea73d60
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-dwarf-linux-product-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-nnbd-mac-release-arm64-try,vm-kernel-precomp-nnbd-linux-release-simarm_x64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-nnbd-linux-release-x64-try,vm-kernel-precomp-nnbd-linux-release-simarm64-try,vm-kernel-precomp-nnbd-linux-debug-simriscv64-try,vm-kernel-precomp-tsan-linux-release-x64-try,vm-kernel-tsan-linux-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/265325
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
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. type-performance Issue relates to performance or code size
Projects
None yet
Development

No branches or pull requests

2 participants