Improve startup time of keyboard shortcut viewer |
||||||||||
Issue descriptionOn veyron_minnie it can take ~800 ms to open. The mus app version adds about 150 ms to this. Comments from issue 847613 : In keyboard-shortcut-viewer, there are needs in the initialization process to layout all the label/views in StyledLabel [1,2]. This is time consuming. [1] https://cs.chromium.org/chromium/src/ash/components/shortcut_viewer/views/keyboard_shortcut_view.cc?l=319&rcl=577ba3637231998f5f807afce564d7f417e7c2aa [2] https://cs.chromium.org/chromium/src/ash/components/shortcut_viewer/views/keyboard_shortcut_item_view.cc?l=172&rcl=92cbc6a3786d9e9e839cf9225672ad62064452aa To study the start-up time for keyboard-shortcut-viewer, we might need to separate the time of startup of the window itself and the time to init and layout the KeyboardShortcutItemListView [1] for all the Side tabs/categories. The layout of KeyboardShortcutItemListView is more time consuming because we dynamically calculate/generate labels in the StyledLabel, which probably is not an generic issue for other apps. [1] https://cs.chromium.org/chromium/src/ash/components/shortcut_viewer/views/keyboard_shortcut_view.cc?l=301&rcl=577ba3637231998f5f807afce564d7f417e7c2aa jamescook@, we do not have separate bug open for KSV init/layout performance. I tested to comment out lines 261 to 275 and the line 282 [1], the mus app version of KSH can start very quick. This indicates that the layout might be the major issue. We did not do as you mentioned, only laying out the first tab and run other tab in the background, which could significantly speed up. There are two bugs related to the layout performance. The first one has been fixed to reduce the search latency and enhance the search experience. The second bug, has more performance requirement, we do not have Milestone target because KSH is not resizable by design. 1. Fixed. bug 818882 : Reduce the latency in search mode of Keyboard Shortcut Viewer 2. The layout performance is the key concern, but debounce might work it around to avoid repeatedly layout: bug 822377: Layout needs to support resizing and maximizes [1] https://cs.chromium.org/chromium/src/ash/components/shortcut_viewer/views/keyboard_shortcut_view.cc?rcl=577ba3637231998f5f807afce564d7f417e7c2aa&l=261 --- I recorded a trace and most of the time is spent in ~450 calls to KeyboardShortcutItemView::MaybeCalculateAndDoLayout. About half the time in that function is spent in RenderTextHarfBuzz::EnsureLayoutRunList, so it's doing some kind of text layout. One idea is to layout just the first tab, then do the other tabs in posted tasks.
,
Jun 8 2018
let's look into this after M70 KSH enhancements.
,
Jun 25 2018
James, I noticed huge difference when compiling w/o is_component_build. Without the flag, the KSV can be opened much faster. But I guess in production we only can use is_component_build = true?
,
Jun 25 2018
I think James said that a lot of that startup delay is from DCHECKs being enabled on our dev builds.
,
Jun 25 2018
I am uncertain as to the cause of the slowdown. Configs that are slow on linux-chromeos even on fast desktop hardware: * Release with dchecks + component * Debug with dchecks + component This is fast: * Release with dchecks, not component However, on device we always use is_component_build = *false* and it's still pretty slow on slow ARM devices.
,
Jun 25 2018
Thanks James, I will try your suggestion to only init labels for active tab and init others in the background or lazy-init.
,
Jul 19
Issue 865286 has been merged into this issue.
,
Jul 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e9a9227483671255fbb14458be5310f62778b60f commit e9a9227483671255fbb14458be5310f62778b60f Author: wutao <wutao@chromium.org> Date: Mon Jul 30 19:57:24 2018 cros: Defer init of background panes in Shortcut Viewer Most of the startup time of Shortcut Viewer is spent to layout the text. This patch only layouts the shortcuts list in the first category and layouts other categories panes in the background. When tested on Linux build: The CreateWidget wall duration is reduced from 403ms to 137ms. The StartupTime is reduced from 1100ms to 900ms. Tested on Eve: The CreateWidget wall duration is reduced from 224ms to 73ms. The StartupTime is reduced from 529ms to 297ms. Bug: 849413 Test: manual. Change-Id: Ia59a90b4eec9c12ba5846883501ee73e8afc8a59 Reviewed-on: https://chromium-review.googlesource.com/1150775 Commit-Queue: Tao Wu <wutao@chromium.org> Reviewed-by: James Cook <jamescook@chromium.org> Cr-Commit-Position: refs/heads/master@{#579130} [modify] https://crrev.com/e9a9227483671255fbb14458be5310f62778b60f/ash/components/shortcut_viewer/views/keyboard_shortcut_view.cc [modify] https://crrev.com/e9a9227483671255fbb14458be5310f62778b60f/ash/components/shortcut_viewer/views/keyboard_shortcut_view.h [modify] https://crrev.com/e9a9227483671255fbb14458be5310f62778b60f/ash/components/shortcut_viewer/views/keyboard_shortcut_view_unittest.cc
,
Sep 17
,
Oct 5
Looks like we have some improvement (avg 900ms to 600ms) by the cl in #8. Close this bug for now. https://uma.googleplex.com/p/chrome/timeline_v2/?sid=90df445b9e59c4ff0da83f8220e4105c |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by bugdroid1@chromium.org
, Jun 4 2018