Skip to content

Use JSON snapshots for all code size tests. NFC #24672

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

RReverser
Copy link
Collaborator

Right now, code size tests in the codebase use two different formats - either everything in a single JSON file, or multiple single-line files.

I found the discrepancy a bit annoying and wanted to unify them.

Between the two, the one with individual files tends to be harder to review as Github (as well as local git tools) add quite a lot of boilerplate UI around each file, you need to manually scan filenames to understand which size diffs are related to each other, and overall feels more difficult to scan quickly as a human.

In this PR I'm unifying both towards a single JSON file format, and other supplementary metadata (imports, sent etc) goes into the same JSON as well so you can see all relevant context together during reviews.

@RReverser RReverser requested a review from sbc100 July 9, 2025 19:41
@RReverser RReverser changed the title Use JSON snapshots for all code size tests Use JSON snapshots for all code size tests. NFC Jul 9, 2025
Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

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

Thanks for doing this! I've been thinking about doing this myself for a while now.

I really like the idea, especially for the code sizes themselves. I'm less sure about the symbol lists since the extra syntax of quotes and commas makes them harder to read than flat files.

Would you consider using json only for the file sizes and continue to use flat files for symbol lists? Or maybe its not worth it?

@RReverser
Copy link
Collaborator Author

Would you consider using json only for the file sizes and continue to use flat files for symbol lists? Or maybe its not worth it?

I could, but I find it kind of nice to have in the same context for the same reason it's nice to have different sizes in the same context - eg there were times when code size increased because some symbol was accidentally exported that shouldn't have been, and then it's helpful for debugging the increase.

I guess we could output YAML / TOML / custom text output if the quotes and commas are the concern?

@sbc100
Copy link
Collaborator

sbc100 commented Jul 9, 2025

Would you consider using json only for the file sizes and continue to use flat files for symbol lists? Or maybe its not worth it?

I could, but I find it kind of nice to have in the same context for the same reason it's nice to have different sizes in the same context - eg there were times when code size increased because some symbol was accidentally exported that shouldn't have been, and then it's helpful for debugging the increase.

I guess we could output YAML / TOML / custom text output if the quotes and commas are the concern?

No this seems fine to me if its useful to have it all together.

test/common.py Outdated
@@ -1694,14 +1697,76 @@ def assertBinaryEqual(self, file1, file2):
self.assertEqual(read_binary(file1),
read_binary(file2))

def check_expected_size_in_file(self, desc, filename, size):
def check_output_sizes(self, outputs: List[str], metadata=None):
test_name = self.id().split('.')[-1]
Copy link
Collaborator

Choose a reason for hiding this comment

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

I guess this makes a lot of sense to set the filename automatically like this, but it would break if we ever had two different test suites with the same test name... i guess that is very unlikely and we would notice right away.

Copy link
Collaborator Author

@RReverser RReverser Jul 9, 2025

Choose a reason for hiding this comment

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

FWIW that's how existing logic already worked in run_codesize_test, I just copied it here.

@RReverser
Copy link
Collaborator Author

(I'll do final rebaseline to fix CI before merging)

@RReverser RReverser requested a review from sbc100 July 11, 2025 10:38
@RReverser
Copy link
Collaborator Author

@sbc100 Anything left on this one? Could be nice to land before eg #24679 as it would make diff much more compact :)

@RReverser RReverser force-pushed the code-size-json branch 2 times, most recently from 09926be to 0bb40ba Compare July 11, 2025 20:02
@RReverser
Copy link
Collaborator Author

RReverser commented Jul 11, 2025

Oh damn I just accidentally added unnecessary files, fixing up... Done.

@RReverser RReverser force-pushed the code-size-json branch 2 times, most recently from 43cda7c to 424ba38 Compare July 11, 2025 20:08
@RReverser RReverser enabled auto-merge (squash) July 12, 2025 01:00
@RReverser
Copy link
Collaborator Author

RReverser commented Jul 12, 2025

@sbc100 I think the CI check expectations script doesn't correctly handle removed/added tests, as it tries to find the same test both before and after this PR and fails.

What is the solution in such cases? Manual merge?

@sbc100
Copy link
Collaborator

sbc100 commented Jul 14, 2025

@sbc100 I think the CI check expectations script doesn't correctly handle removed/added tests, as it tries to find the same test both before and after this PR and fails.

What is the solution in such cases? Manual merge?

Fair enough we can bypass that check for this PR.

@RReverser
Copy link
Collaborator Author

Fair enough we can bypass that check for this PR.

Can you please do it? I don't have the bypass rights :(

@RReverser
Copy link
Collaborator Author

I rebaselined & fixed conflicts again, but it might need yet another rebaseline right before you merge it.

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

Successfully merging this pull request may close these issues.

2 participants