-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
feat: Track the binary size for all the different platforms #34744
base: main
Are you sure you want to change the base?
Conversation
Some unsure points:
Edit: Currently all resolved. I've tested a full run with additional production profile and the duration is actually the same as a release profile only, because ultimately the bottleneck is WPT tests and production profile actually runs pretty fast. I think we can just do everything all at once for each commit. Here's a full run: https://github.com/dklassic/servo/actions/runs/12485231562 |
6922cac
to
3d9cbac
Compare
Also I notice that bencher seems to report in MB now but the unit remains to be Bytes I've reported an upstream issue for this: bencherdev/bencher#545 |
Wow, that's a lot of files. Can we remove repetition by making bencher workflow more generic (argument to accept os to get full binary name, all test to do in bencher bin, speedometer, dromeo) or at least use composable github action. |
Yeah that's probably the way to go, I'm just naively hacking it out to see if the overall workflow makes sense or not. |
cc1f3fd
to
26c6fef
Compare
🛠 These changes could not be applied onto the latest upstream WPT. Servo's copy of the Web Platform Tests may be out of sync. |
4 similar comments
🛠 These changes could not be applied onto the latest upstream WPT. Servo's copy of the Web Platform Tests may be out of sync. |
🛠 These changes could not be applied onto the latest upstream WPT. Servo's copy of the Web Platform Tests may be out of sync. |
🛠 These changes could not be applied onto the latest upstream WPT. Servo's copy of the Web Platform Tests may be out of sync. |
🛠 These changes could not be applied onto the latest upstream WPT. Servo's copy of the Web Platform Tests may be out of sync. |
684ddc5
to
b35ddd8
Compare
🛠 These changes could not be applied onto the latest upstream WPT. Servo's copy of the Web Platform Tests may be out of sync. |
b35ddd8
to
922c253
Compare
🛠 These changes could not be applied onto the latest upstream WPT. Servo's copy of the Web Platform Tests may be out of sync. |
1 similar comment
🛠 These changes could not be applied onto the latest upstream WPT. Servo's copy of the Web Platform Tests may be out of sync. |
🛠 These changes could not be applied onto the latest upstream WPT. Servo's copy of the Web Platform Tests may be out of sync. |
So I've tested a full run with additional production profile and the duration is actually the same as a release profile only, because ultimately the bottleneck is WPT tests and production profile actually runs pretty fast. I think we can just do everything all at once for each commit. Here's a full run: https://github.com/dklassic/servo/actions/runs/12485231562 |
🛠 These changes could not be applied onto the latest upstream WPT. Servo's copy of the Web Platform Tests may be out of sync. |
2 similar comments
🛠 These changes could not be applied onto the latest upstream WPT. Servo's copy of the Web Platform Tests may be out of sync. |
🛠 These changes could not be applied onto the latest upstream WPT. Servo's copy of the Web Platform Tests may be out of sync. |
@dklassic Please squash and rebase before merging. Each commit is a line in the final commit message, so 60 commits will be quite long. |
a9e978a
to
3b96fc0
Compare
@jschwe just pinging to make sure this PR is not lost in all the moving parts. Feels like we should get it running soon and start tracking the numbers if there’s no other complications. |
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.
LGTM and I think we should start tracking the size if possible.
If no one disagrees, I'll merge this later.
bba9846
to
2e19ac0
Compare
5a65ee4
to
cef1fd7
Compare
https://github.com/dklassic/servo/actions/runs/12665377293 Added workflow setup to be shown on the job name, should look way clearer what each workflow is doing now. |
89d2cfb
to
e16e658
Compare
https://github.com/dklassic/servo/actions/runs/12675323101 Okay I think I got it all ready. |
Signed-off-by: DK Liao <dklassic@gmail.com>
383b7a6
to
8f38b97
Compare
@sagudev do you mind see if there's any other improvements that can be made? |
echo "SERVO_FILE_SIZE_RESULT=size.json" >> "$GITHUB_ENV" | ||
# We'll additionally strip and measure the size of the binary when using production profile | ||
- name: Install LLVM | ||
if: ${{ inputs.stripped-file-size == true }} |
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.
Do we need this additional input option? Couldn't just check if profile == production
?
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.
For ohos binaries, stripping them with llvm directly doesn’t seem to work atm.
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.
What kind of errors are you encountering? I've been using the standard llvm installed on my system to strip libservoshell.so without problems.
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.
I suppose I'm doing it wrongly then, here's the error:
https://github.com/dklassic/servo/actions/runs/12481534299/job/34834716773#step:13:21
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.
Ah, We shouldn't be measuring the .hap file, we should measure the libservoshell.so
dynamic library, since that is what we develop here. The .hap is kind of like an apk file on android. For android I would recommend the same, measure libservoshell.so
, since that is where our code is.
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.
Ah right, that would make sense, I'll make changes on that.
While we're at it, may I borrow your wisdom on Android Production profile? I'm not sure if it is expected but simply running Android workflow with Production profile will lead to the following error:
https://github.com/dklassic/servo/actions/runs/12488632199/job/34851264188#step:14:1108
So currently the setup skips production build on Android, but maybe it's just me missing something again.
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.
Ah, yes I encountered that issue when building android too. It comes from here:
servo/python/servo/package_commands.py
Line 164 in 73c0701
raise Exception("TODO what should this be?") |
Edit: I see I had opened an issue: #34564
stripped-file-size: ${{ inputs.profile == 'production' }} | ||
# We only evaluate speedometer and dromaeo score in release | ||
speedometer: ${{ inputs.profile == 'release' }} | ||
dromaeo: ${{ inputs.profile == 'release' }} |
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.
Couldn't speedometer and dromaeo be release
or production?
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.
I guess we can track the scores for production profile as well, not sure if warranted atm though.
For now what it does are:
macos-${{ inputs.profile }}
windows-${{ inputs.profile }}
linux-${{ inputs.profile }}
android-${{ matrix.target }}-${{ inputs.profile }}
ohos-${{ matrix.target }}-${{ inputs.profile }}
The linux-bencher.yml has been heavily modified to be a generic bencher workflow for any target.
./mach build -d
does not report any errors./mach test-tidy
does not report any errors