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

sql/catalog: reduce NameKey allocations #136234

Merged
merged 4 commits into from
Nov 27, 2024

Conversation

mgartner
Copy link
Collaborator

@mgartner mgartner commented Nov 26, 2024

sql/catalog: change LookupNamespaceEntry parameter type

The Catalog.LookupNamespaceEntry method now accepts the concrete type
descpb.NameInfo instead of the catalog.NameKey interface. This,
along with future commits, will help reduce allocations.

Release note: None

sql/catalog: change IsNameInCache parameter type

The CatalogReader.IsNameInCache method now accepts the concrete type
descpb.NameInfo instead of the catalog.NameKey interface. This,
along with other commits, will help reduce allocations.

Release note: None

sql/catalog: change (*Collection).isShadowedName parameter type

The (*Collection).isShadowedName method now accepts the concrete type
descpb.NameInfo instead of the catalog.NameKey interface. This,
along with other commits, will help reduce allocations.

Informs #105867
Fixes #135905
Fixes #121300

Release note: None

sql/catalog: refactor (*SystemDatabaseCache).lookupDescriptorID

Now that (*SystemDatabaseCache).lookupDescriptorID accepts a
descpb.NameInfo parameter, it can access its exported field directly
instead of using getters.

Release note: None

The `Catalog.LookupNamespaceEntry` method now accepts the concrete type
`descpb.NameInfo` instead of the `catalog.NameKey` interface. This,
along with future commits, will help reduce allocations.

Release note: None
The `CatalogReader.IsNameInCache` method now accepts the concrete type
`descpb.NameInfo` instead of the `catalog.NameKey` interface. This,
along with other commits, will help reduce allocations.

Release note: None
The `(*Collection).isShadowedName` method now accepts the concrete type
`descpb.NameInfo` instead of the `catalog.NameKey` interface. This,
along with other commits, will help reduce allocations.

Release note: None
@mgartner mgartner added the o-perf-efficiency Related to performance efficiency label Nov 26, 2024
@mgartner mgartner requested a review from a team as a code owner November 26, 2024 19:10
@cockroach-teamcity
Copy link
Member

This change is Reviewable

@mgartner
Copy link
Collaborator Author

BenchmarkEndToEnd/kv-read shows the improvement:

name                                     old time/op    new time/op    delta
EndToEnd/kv-read/vectorize=on/Simple        422µs ±10%     422µs ± 4%    ~     (p=0.690 n=5+5)
EndToEnd/kv-read/vectorize=on/Prepared      272µs ± 6%     276µs ± 2%    ~     (p=0.841 n=5+5)
EndToEnd/kv-read/vectorize=off/Simple       415µs ± 2%     428µs ± 7%    ~     (p=0.690 n=5+5)
EndToEnd/kv-read/vectorize=off/Prepared     269µs ± 4%     271µs ± 6%    ~     (p=1.000 n=5+5)

name                                     old alloc/op   new alloc/op   delta
EndToEnd/kv-read/vectorize=on/Simple       36.2kB ± 1%    36.0kB ± 1%    ~     (p=0.343 n=4+4)
EndToEnd/kv-read/vectorize=on/Prepared     25.9kB ±16%    26.0kB ±17%    ~     (p=1.000 n=5+5)
EndToEnd/kv-read/vectorize=off/Simple      37.8kB ± 4%    38.1kB ±11%    ~     (p=0.421 n=5+5)
EndToEnd/kv-read/vectorize=off/Prepared    26.0kB ± 2%    25.8kB ± 0%    ~     (p=0.111 n=5+4)

name                                     old allocs/op  new allocs/op  delta
EndToEnd/kv-read/vectorize=on/Simple          321 ± 0%       311 ± 0%  -3.19%  (p=0.029 n=4+4)
EndToEnd/kv-read/vectorize=on/Prepared        237 ±12%       233 ±13%    ~     (p=0.190 n=5+5)
EndToEnd/kv-read/vectorize=off/Simple         313 ± 0%       303 ± 0%  -3.19%  (p=0.029 n=4+4)
EndToEnd/kv-read/vectorize=off/Prepared       221 ± 0%       216 ± 0%  -2.09%  (p=0.000 n=5+4)

@rafiss
Copy link
Collaborator

rafiss commented Nov 26, 2024

does this close out #121300 and #135905?

Copy link
Collaborator

@rafiss rafiss left a comment

Choose a reason for hiding this comment

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

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @mgartner)


pkg/sql/catalog/internal/catkv/system_database_cache.go line 90 at r4 (raw file):

	version clusterversion.ClusterVersion, key descpb.NameInfo,
) (descpb.ID, hlc.Timestamp) {
	// TODO: Refactor this a bit.

nit: can this comment provide a clue as to what we'd like to refactor?

Now that `(*SystemDatabaseCache).lookupDescriptorID` accepts a
`descpb.NameInfo` parameter, it can access its exported field directly
instead of using getters.

Release note: None
@mgartner mgartner force-pushed the reduce-namekey-allocs branch from 2d6dbb6 to 725bebf Compare November 27, 2024 15:52
@mgartner mgartner requested a review from rafiss November 27, 2024 15:52
Copy link
Collaborator Author

@mgartner mgartner left a comment

Choose a reason for hiding this comment

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

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @rafiss)


pkg/sql/catalog/internal/catkv/system_database_cache.go line 90 at r4 (raw file):

Previously, rafiss (Rafi Shamim) wrote…

nit: can this comment provide a clue as to what we'd like to refactor?

Oops, that was a left-over comment. This commit already does the refactoring. Good catch!

@mgartner
Copy link
Collaborator Author

does this close out #121300 and #135905?

Yes, it fixes both of them. I've added them to the PR description. Thanks for finding those!

@mgartner
Copy link
Collaborator Author

TFTR!

bors r+

@craig craig bot merged commit 915b7c8 into cockroachdb:master Nov 27, 2024
22 of 23 checks passed
@mgartner mgartner deleted the reduce-namekey-allocs branch November 27, 2024 22:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
o-perf-efficiency Related to performance efficiency
Projects
None yet
3 participants