Repository navigation
Abertura a frio do teclado: para onde vai o tempo no emulador, e a comparação com o Gboard corrigida - #10
Merged
Conversation
… a comparação com o Gboard corrigida Traces do Perfetto do OpeningBenchmarks (20 voltas) e do Gboard: o 1º quadro do teclado a frio gasta 300–600 ms criando o contexto gráfico e 60–900 ms compilando ~10 programas de GPU, que a GPU emulada (ANGLE sobre SwiftShader, sem GL_OES_get_program_binary) não deixa o Android guardar — todo processo novo recompila, o do Gboard também. O nosso código soma 20–65 ms. A comparação "KeyFlow 6/8 × Gboard 1/8 aberturas em transição" estava errada: com 4 s de observação o Gboard a frio (3,8 s para aparecer) quase não era amostrado. O ime-placement.py agora diz em quantos segundos o teclado fica visível e no lugar de vez, avisa quando ele nem apareceu e repete o ime set depois do force-stop. Medido certo: KeyFlow 2,0 s / 2,9 s, Gboard 3,8 s / 4,0 s; a transição que sobra no KeyFlow vem do tipo de janela (altura do teclado, redimensionada depois de aparecer), não de lentidão.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Análise dos traces do Perfetto guardados pelo
OpeningBenchmarks(20 voltas no emulador com a CPU limitada como o CI) e de um trace do sistema do Gboard.O que os traces mostram
Do ~1 s do 1º quadro do teclado a frio no emulador:
Creating EGLContext, só chamadasrc… encodedo emulador)shader_compile, semprecache_miss)A GPU do emulador (ANGLE sobre SwiftShader) não tem
GL_OES_get_program_binary: o Android não consegue guardar os programas compilados (code_cache/vazio, o do Gboard também) e todo processo novo recompila tudo. O Gboard paga o mesmo contexto gráfico (302–318 ms).Correção
TESTING.mddizia "KeyFlow 6/8 aberturas em transição, Gboard 1/8". A comparação estava errada: com 4 s de observação o Gboard a frio, que leva 3,8 s para aparecer, quase não era amostrado. Medido com 12 s e o app compilado: KeyFlow visível em 2,0 s e no lugar de vez em 2,9 s; Gboard 3,8 s e 4,0 s. A transição que sobra no KeyFlow vem do tipo de janela (altura do teclado, redimensionada depois de aparecer; a do Gboard tem a altura da tela desde o início).scripts/ime-placement.pyagora mostra em quantos segundos o teclado fica visível e no lugar de vez, avisa quando ele nem apareceu na janela de observação e repete oime setdepois do force-stop.Só script de medição e documentação: nenhum código do app nem de teste muda.