These seem like performance sensitive paths in here. Was there any analysis done on how this impacts performance of e.g. Speedometer?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
These seem like performance sensitive paths in here. Was there any analysis done on how this impacts performance of e.g. Speedometer?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Xiang JiThese seem like performance sensitive paths in here. Was there any analysis done on how this impacts performance of e.g. Speedometer?
No, how to use speedometer? Is there a try job for it?
It can be executed on pinpoint via `speedometer3.crossbench` benchmark, see https://chromium.googlesource.com/chromium/src/+/main/docs/benchmark_performance_regressions.md
We should not blindly replace UNSAFE_TODO with AI when we are not sure that there's no critical performance impact here. `wtf/` seems not a like a good area to automate this without having any context of the codebase.
Since this is all landed incrementally: How do we ensure that we don't destroy progress here via death of 1000 cuts?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Xiang JiThese seem like performance sensitive paths in here. Was there any analysis done on how this impacts performance of e.g. Speedometer?
Michael LippautzNo, how to use speedometer? Is there a try job for it?
It can be executed on pinpoint via `speedometer3.crossbench` benchmark, see https://chromium.googlesource.com/chromium/src/+/main/docs/benchmark_performance_regressions.md
We should not blindly replace UNSAFE_TODO with AI when we are not sure that there's no critical performance impact here. `wtf/` seems not a like a good area to automate this without having any context of the codebase.
Since this is all landed incrementally: How do we ensure that we don't destroy progress here via death of 1000 cuts?
https://pinpoint-dot-chromeperf.appspot.com/job/14857c2b890000
https://pinpoint-dot-chromeperf.appspot.com/job/14857c2b890000
Seems they're run in cq.
Are span array supposed to be slower? Shall we skip blink folders entirely?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Xiang JiThese seem like performance sensitive paths in here. Was there any analysis done on how this impacts performance of e.g. Speedometer?
Michael LippautzNo, how to use speedometer? Is there a try job for it?
Xiang JiIt can be executed on pinpoint via `speedometer3.crossbench` benchmark, see https://chromium.googlesource.com/chromium/src/+/main/docs/benchmark_performance_regressions.md
We should not blindly replace UNSAFE_TODO with AI when we are not sure that there's no critical performance impact here. `wtf/` seems not a like a good area to automate this without having any context of the codebase.
Since this is all landed incrementally: How do we ensure that we don't destroy progress here via death of 1000 cuts?
https://pinpoint-dot-chromeperf.appspot.com/job/14857c2b890000
https://pinpoint-dot-chromeperf.appspot.com/job/14857c2b890000
Seems they're run in cq.Are span array supposed to be slower? Shall we skip blink folders entirely?
https://pinpoint-dot-chromeperf.appspot.com/job/14857c2b890000
https://pinpoint-dot-chromeperf.appspot.com/job/14857c2b890000
Can you start with more repetitions? The results seem bogus.
Are span array supposed to be slower?
Authors should know what they send out...
spans hard check their bounds which causes some sensitive areas to get slower. This may or may not be the case here.
Shall we skip blink folders entirely?
This is not a discussion that should be had on this CL here. There were spanification efforts in the past and some areas were intentionally skipped due to being performance critical. `wtf/` is one of these very sensitive areas. chrome-memory-safety@ is probably a good alias for a larger discussion.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |