-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Use more compact storage for impl lookup buckets. #4351
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
be3e988
to
3b8650f
Compare
There was a problem hiding this 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.
toolchain/sem_ir/impl.h
Outdated
// An ID of either a single impl or a lookup bucket. | ||
class ImplOrLookupBucketId : public IdBase { | ||
public: | ||
using IdBase::IdBase; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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.
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>
eead722
to
78e319d
Compare
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.