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

Micro-optimizate memory usage in CatCacheCopyKeys #283

Open
tristan957 opened this issue May 30, 2023 · 3 comments
Open

Micro-optimizate memory usage in CatCacheCopyKeys #283

tristan957 opened this issue May 30, 2023 · 3 comments
Assignees

Comments

@tristan957
Copy link
Member

CatCacheCopyKeys has this:


	/*
	 * XXX: memory and lookup performance could possibly be improved by
	 * storing all keys in one allocation.
	 */

That seems like a good idea. We'd like to reduce backend memory usage. This is a very small part of it, but it's also a very localized change.

Also, this function often deals with the 'name' type. 'name' is a fixed-width type, 64 bytes wide (NAMEDATALEN to be precise). However, it's always null-terminated, and the functions in catcache.c like nameeqfast and namehashfast treat it as a C string. So we don't really need to alloc and copy the whole 64 bytes, we could call strlen() here and leave out the trailing zeros.

Tasks:

  • Create a test case that shows the benefit. Something that creates a lot of catcache entries, and measure the memory usage.
  • Do the above optimizations
@tristan957 tristan957 self-assigned this May 30, 2023
@tristan957
Copy link
Member Author

I believe I have the optimization for the string case done. Being unfamiliar with this portion of code, I don't necessarily understand how best to test it.

@tristan957
Copy link
Member Author

It seems like using enums might test this code out, not sure though.

@andreasscherbaum
Copy link

Status: nice side project which might yield an upstream patch.

Needs more tests, numbers, and the actual patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants