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

GH Action for FLASH size diff #23867

Closed
wants to merge 2 commits into from
Closed

GH Action for FLASH size diff #23867

wants to merge 2 commits into from

Conversation

alexcekay
Copy link
Member

Solved Problem

Increase awareness of the impact of a code change on FLASH size. Allow developers to see exactly how much and where their change will increase FLASH usage.

Solution

  • In case of a PR:
    • Compile the base revision
    • Compile the current revision of the branch
    • Diff the flash usage using bloaty
  • In case of a commit on main:
    • Compile the previous main revision
    • Compile the current main revision
    • Diff the flash usage using bloaty

Alternatives / Future

This is an initial working version that includes the following two boards:

  • px4_fmu-v5x
  • px4_fmu-v6x

If we want, we can easily add more boards in the future.

This version compiles 2 times for each board (1 compile before / 1 compile after) to create the diff. With two boards this results in 4 compiles, which is fast and only creates a small overhead. If we add many more boards, we should reuse the artifacts created by other jobs. However, this will increase the complexity of the code as an external script will need collect the artifacts from the base and current revisions and unpack them.

Copy link

FLASH Analysis

px4_fmu-v5x
    FILE SIZE        VM SIZE    
 --------------  -------------- 
  +0.0%      +8  +0.0%      +8    .text
  -0.0%      -8  [ = ]       0    [Unmapped]
  [ = ]       0  +0.0%      +8    TOTAL

px4_fmu-v6x
    FILE SIZE        VM SIZE    
 --------------  -------------- 
  +0.0%      +8  +0.0%      +8    .text
  -0.0%      -8  [ = ]       0    [Unmapped]
  [ = ]       0  +0.0%      +8    TOTAL

@alexcekay alexcekay closed this Oct 30, 2024
@PetervdPerk-NXP
Copy link
Member

The bloaty build in px4io/px4-dev-nuttx-focal tends to segfault time to time.
Could we, use a more updated container?

Also maybe include ram as well and only trigger on a big delta.

@alexcekay
Copy link
Member Author

alexcekay commented Nov 1, 2024

Hi @PetervdPerk-NXP,
I closed this PR and moved it to this one #23868.
Regarding your comment:

  • Do you have an example of the bloaty build causing a segfault. It did not happen yet on any of the tests of the action on my fork. With an example of the segfault I can diff which version is used there and in my action.
  • Regarding RAM: The static RAM part is included in bloaty via .bss and .data. This is however only a rather small part in PX4 due to most of the RAM usage being caused by mallocs. We plan to add a dynamic execution for measuring RAM (heap) usage

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