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.

Sign up for GitHub

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

Jump to bottom

Automatically enable fps debug while running a test #5

Merged
merged 3 commits into from Aug 5, 2022
Merged

Automatically enable fps debug while running a test #5

merged 3 commits into from Aug 5, 2022

Conversation

MaeIg
Copy link
Contributor

@MaeIg MaeIg commented Aug 5, 2022 •
edited

Before After
image image

@MaeIg
feat(fps): auto enable debug.hwui.profile
e68233d
@MaeIg
docs(fps): update README
8e1bb6b
@MaeIg
test: repair tests
0d64397 
1. Don't run e2e test examples
2. Add new adb command to child_process mock
@Almouro Almouro merged commit 741877c into bamlab:main Aug 5, 2022
@MaeIg MaeIg deleted the auto-activate-fps-debug branch August 5, 2022 21:24
Almouro added a commit that referenced this pull request Jul 27, 2023
@Almouro
fix(profiler): handle multiple processes with same name
9101173 
This is similar to what Android Studio displays

Say you have an app loading several images, chances are the app will create a different process to load each images but with the same name
For instance, let's say this launches 5 different processes each accounting for 20% CPU usage in the same 500ms window

Before this fix, the stats would be additionned, meaning we would see one single thread with that name with 100% CPU usage. It would thus hit the high CPU usage threshold, even though, nothing is actually saturating

After this fix you would see
process 20%
process #2 20%
...
process #5 20%

Worth noting that a more ideal fix would have been to store processes by ids, but that actually makes the list of processes less readable and more difficult to compare
Say every 500ms you load 5 requests, your 5 request processes would get recreated with same name but different ids, so every 500ms, 5 new processes would get added to the list. By still grouping by name, but allowing for multiple occurrences in a 500ms window, we keep only a smaller amount of processes, like Android Studio does for instance.
It's also easier to compare and track with multiple iterations
Almouro added a commit that referenced this pull request Jul 27, 2023
@Almouro
fix(profiler): handle multiple processes with same name
1a88c01 
This is similar to what Android Studio displays

Say you have an app loading several images, chances are the app will create a different process to load each images but with the same name
For instance, let's say this launches 5 different processes each accounting for 20% CPU usage in the same 500ms window

Before this fix, the stats would be additionned, meaning we would see one single thread with that name with 100% CPU usage. It would thus hit the high CPU usage threshold, even though, nothing is actually saturating

After this fix you would see
process 20%
process #2 20%
...
process #5 20%

Worth noting that a more ideal fix would have been to store processes by ids, but that actually makes the list of processes less readable and more difficult to compare
Say every 500ms you load 5 requests, your 5 request processes would get recreated with same name but different ids, so every 500ms, 5 new processes would get added to the list. By still grouping by name, but allowing for multiple occurrences in a 500ms window, we keep only a smaller amount of processes, like Android Studio does for instance.
It's also easier to compare and track with multiple iterations
Almouro added a commit that referenced this pull request Jul 27, 2023
@Almouro
fix(profiler): handle multiple processes with same name
fe47958 
This is similar to what Android Studio displays

Say you have an app loading several images, chances are the app will create a different process to load each images but with the same name
For instance, let's say this launches 5 different processes each accounting for 20% CPU usage in the same 500ms window

Before this fix, the stats would be additionned, meaning we would see one single thread with that name with 100% CPU usage. It would thus hit the high CPU usage threshold, even though, nothing is actually saturating

After this fix you would see
process 20%
process #2 20%
...
process #5 20%

Worth noting that a more ideal fix would have been to store processes by ids, but that actually makes the list of processes less readable and more difficult to compare
Say every 500ms you load 5 requests, your 5 request processes would get recreated with same name but different ids, so every 500ms, 5 new processes would get added to the list. By still grouping by name, but allowing for multiple occurrences in a 500ms window, we keep only a smaller amount of processes, like Android Studio does for instance.
It's also easier to compare and track with multiple iterations
Almouro added a commit that referenced this pull request Jul 27, 2023
@Almouro
fix(profiler): handle multiple processes with same name
f8c6490 
This is similar to what Android Studio displays

Say you have an app loading several images, chances are the app will create a different process to load each images but with the same name
For instance, let's say this launches 5 different processes each accounting for 20% CPU usage in the same 500ms window

Before this fix, the stats would be additionned, meaning we would see one single thread with that name with 100% CPU usage. It would thus hit the high CPU usage threshold, even though, nothing is actually saturating

After this fix you would see
process 20%
process #2 20%
...
process #5 20%

Worth noting that a more ideal fix would have been to store processes by ids, but that actually makes the list of processes less readable and more difficult to compare
Say every 500ms you load 5 requests, your 5 request processes would get recreated with same name but different ids, so every 500ms, 5 new processes would get added to the list. By still grouping by name, but allowing for multiple occurrences in a 500ms window, we keep only a smaller amount of processes, like Android Studio does for instance.
It's also easier to compare and track with multiple iterations
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Almouro Almouro Almouro approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@MaeIg @Almouro