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

Use more compact storage for impl lookup buckets. #4351

Merged
merged 4 commits into from
Sep 29, 2024

Conversation

zygoloid
Copy link
Contributor

If the bucket is of size zero or one, which is expected to be the common
case, then store it directly. For the remaining cases, use a side table
of lookup buckets.

@zygoloid

This comment was marked as resolved.

@zygoloid zygoloid added the dependent Depends on another issue/PR label Sep 27, 2024
Copy link
Contributor

@jonmeow jonmeow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Leaving it to you to figure out merging.

// An ID of either a single impl or a lookup bucket.
class ImplOrLookupBucketId : public IdBase {
public:
using IdBase::IdBase;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had you considered making the constructor private in order to emphasize use of the factory functions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@@ -57,22 +57,110 @@ struct Impl : public EntityWithParamsBase,
// A collection of `Impl`s, which can be accessed by the self type and
// constraint implemented.
class ImplStore {
private:
// An ID of either a single impl or a lookup bucket.
class ImplOrLookupBucketId : public IdBase {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Abstractly, we have a couple other things which have TinyPtrVector-like TODOs. Particularly NameScope's extended_scopes had seemed similar, but this approach won't work for it (I think it'd need to own the vector). I think this approach is fine, but I wanted to note this because I don't think this approach would work directly in other use-cases; I'm not sure precisely where the trade-offs stand to try to get something generally applicable.

toolchain/sem_ir/impl.h Show resolved Hide resolved
zygoloid and others added 2 commits September 27, 2024 21:50
If the bucket is of size zero or one, which is expected to be the common
case, then store it directly. For the remaining cases, use a side table
of lookup buckets.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
@zygoloid zygoloid removed the dependent Depends on another issue/PR label Sep 27, 2024
@zygoloid zygoloid added this pull request to the merge queue Sep 27, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Sep 27, 2024
@zygoloid zygoloid added this pull request to the merge queue Sep 28, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Sep 28, 2024
@zygoloid zygoloid added this pull request to the merge queue Sep 29, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Sep 29, 2024
@zygoloid zygoloid added this pull request to the merge queue Sep 29, 2024
Merged via the queue into carbon-language:trunk with commit 9d5ec52 Sep 29, 2024
8 checks passed
@zygoloid zygoloid deleted the toolchain-lookup-bucket branch September 29, 2024 17:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants