Skip to content

Remove unnecessary StringName idx cache in _Data to reduce its size. #105760

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

Merged
merged 1 commit into from
Apr 28, 2025

Conversation

Ivorforce
Copy link
Member

The size is reduced by 8 bytes in DEBUG, and 0 bytes (no change) in RELEASE - both because of padding.

I'm also taking the opportunity to encapsulate StringName details in its cpp file (same as in #104372), and doing some other cleanup that doesn't warrant an entire pull request.
This allows making changes to the table (such as changing size) internally without having everything be recompiled.

@Ivorforce Ivorforce added this to the 4.x milestone Apr 25, 2025
@Ivorforce Ivorforce requested a review from a team as a code owner April 25, 2025 17:10
…size by 4 bytes.

Encapsulate `StringName` details in its cpp file.
Copy link
Member

@Calinou Calinou left a comment

Choose a reason for hiding this comment

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

Tested locally, it works as expected. Code looks good to me.

Note that this PR doesn't affect binary size (size reduction is only in memory).

@Ivorforce Ivorforce modified the milestones: 4.x, 4.5 Apr 25, 2025
bool StringName::_Data::operator!=(const char *p_name) const {
return !operator==(p_name);
}
static inline _Data *table[TABLE_LEN];
Copy link
Contributor

Choose a reason for hiding this comment

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

Does static inline _Data *table[TABLE_LEN] = {}; not 0 initialize it, so we could remove the setup call altogether ?

Copy link
Member Author

Choose a reason for hiding this comment

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

It would. But it's out of scope. It probably makes sense to allocate at runtime anyway to avoid the 500kb bloating the binary.

Copy link
Contributor

Choose a reason for hiding this comment

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

I thought standard forced static arrays to be zero initialized anyway, but I'm not sure with inline. And it would probably be put in the bss section, so it would not bloat anything (but making sure no compiler options is messing with that would be the no fun part)

Copy link
Member Author

@Ivorforce Ivorforce Apr 27, 2025

Choose a reason for hiding this comment

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

And it would probably be put in the bss section, so it would not bloat anything (but making sure no compiler options is messing with that would be the no fun part)

I'm pretty sure bloaty told me the table made up 500kb of the final binary. I was planning on testing this again (along with potential speed impact) when I prepare the according PR.

I thought standard forced static arrays to be zero initialized anyway, but I'm not sure with inline.

Makes sense to me! inline in this case just means it is defined where it's declared (and doesn't have to be put into the cpp), so that shouldn't have any effect.

@Repiteo Repiteo merged commit ba0ad48 into godotengine:master Apr 28, 2025
20 checks passed
@Repiteo
Copy link
Contributor

Repiteo commented Apr 28, 2025

Thanks!

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.

4 participants