Esta é a abordagem errada. Especialmente porque o testador visual tem um modelo diferente de renderização retardada, de modo a não retardar completamente o processo de teste.
Entendo. Portanto,além de medir no testador, você terá que medir no gráfico.
Renat Fatkhullin:
Eu não disse isso.
Apontei os erros óbvios e expliquei como funciona o sistema de renderização.
com o modelo de evento Windows - mesmo que você mova o mouse rapidamente, a carga da CPU começa a aumentar, não importa qual aplicação estava em foco
SZY: Verifiquei-o no gerenciador de tarefas em Win10... Não mostrando qualquer aumento na carga da CPU por algum motivo, em Win7 exatamente a mesma carga estava aumentando se eu movesse o mouse rapidamente - duvido que Win10 tenha mudado drasticamente o modelo do evento, muito provavelmente o gerente de tarefas trabalha de uma maneira diferente
Vin10. Aqui está a trama quando eu movo o mouse na janela de entrada desta mensagem de texto com o LKM pressionado
Vin10. Aqui está a trama quando eu movo o mouse na janela de entrada desta mensagem de texto com o LKM pressionado
Aqui está sem o LKM.
não óbvio
Aqui está a área de trabalho virtual com Win7 - se eu não mover o mouse, ele carrega a CPU 3-4%.
se o mouse está se movendo rápido - 11-14% de carga
Quero dizer que a fila de mensagens em Win sempre precisa ser processada, mas são ciclos extras da CPU - google "janela C++" - qualquer manual para escrever aplicações de janelas em C++ usando WinAPI, leia lá sobre o gerenciador de mensagens
de uma máquina virtual sob Win7 - se você não mover o mouse, 3-4% de carga na CPU
se o mouse está se movendo rápido - 11-14% de carga de CPU
Quero dizer que a fila de mensagens em Win sempre precisa ser processada e são necessários ciclos extras de CPU - google "c++ windows window".
Para colocar em números mais claros, não estou fazendo nada - 10-15 flutua, 17-30 ao mover-se.
Mas se isso fizer com que o OnTimer desacelere 2 vezes, não, é claro, a menos que com 95-99% de carga.
Qualquer manual de aplicação de janela do Windows em C++ usando WinAPI, leia lá sobre o gerenciador de mensagens
o manipulador de mensagens ocupa uma fração da CPU como está, só não é usado quando não há fila. Para processos MT, não deve haver redução do tempo de processamento com esta carga.
Mas se isso fizer com que o OnTimer abrande duas vezes, não, é claro, exceto para 95-99% de carga.
O timer também é um evento WinAPI, mas duvido que cada programa MQL subscreva o timer do sistema - ele imita o ambiente MQL(máquina virtual)
Aleksey Mavrin:
O manipulador de mensagens aceita compartilhamento de CPU e assim por diante, só não é usado quando não há fila de espera. Para processos MT não deve haver corte de tempo de CPU nesta carga.
Há sempre uma fila em uma janela ativa. É uma fila comum de folhas de café. Adivinhe como esta fila é distribuída pelo terminal entre gráficos e depois entre os programas MQL.
bem, no final - para obter um modo monopólio e não processar mensagens - não há muitas opções, a primeira que vem - aplicação exclusiva em modo tela cheia, mas essa é outra história, como se fosse a "batalha por recursos PC", então você só precisa de uma API para ir até a troca e escrever sua aplicação, e lá registrar a janela ou não
ok, não estou interessado em procurar por pico de carga de CPU - desde que estejamos em Vin, tudo pode acontecer, geralmente estou bem com isso
O timer também é um evento WinAPI, mas duvido que cada programa MQL subscreva o timer do sistema - ele imita o ambiente MQL(máquina virtual)
não é um fato. se você se lembra que havia um bug com timer e número de manipuladores no terminal, indiretamente sugere que cada timer no MT pode muito bem ser um jogo de vinho do sistema
Sim, não vi que se tratava de uma tabela interna.
Bem a julgar pelo perfil, a fonte dos freios, ao rolar o gráfico, está nesta linha:
Perfilagem com rolagem ativa:
Perfilamento com movimento ativo do mouse sem rolagem (sem o LKM pressionado):
ZS: Afinal, a fonte dos freios não é o kanvas, mas os objetos.
Infelizmente, o meu perfil deste código dá um espaço em branco. b2828.
Infelizmente, o meu perfil deste código dá um espaço em branco. b2828.
Parece que eles ainda não terminaram o perfilador. Eu também costumava ter um branco às vezes. Mas agora funciona.

Funciona com este também.

Esta é a abordagem errada. Especialmente porque o testador visual tem um modelo diferente de renderização retardada, de modo a não retardar completamente o processo de teste.
Entendo. Portanto,além de medir no testador, você terá que medir no gráfico.
Eu não disse isso.
Apontei os erros óbvios e expliquei como funciona o sistema de renderização.
Bem, então entendi tudo errado. Desculpe.
Parece que eles ainda não terminaram o perfilador. Eu também costumava ter um branco às vezes. Mas agora funciona.
este também funciona.
Eu também não tenho nada sobre o b2830.
com o modelo de evento Windows - mesmo que você mova o mouse rapidamente, a carga da CPU começa a aumentar, não importa qual aplicação estava em foco
SZY: Verifiquei-o no gerenciador de tarefas em Win10... Não mostrando qualquer aumento na carga da CPU por algum motivo, em Win7 exatamente a mesma carga estava aumentando se eu movesse o mouse rapidamente - duvido que Win10 tenha mudado drasticamente o modelo do evento, muito provavelmente o gerente de tarefas trabalha de uma maneira diferente
Vin10. Aqui está a trama quando eu movo o mouse na janela de entrada desta mensagem de texto com o LKM pressionado
Aqui está sem o LKM
Vin10. Aqui está a trama quando eu movo o mouse na janela de entrada desta mensagem de texto com o LKM pressionado
Aqui está sem o LKM.
não óbvio
Aqui está a área de trabalho virtual com Win7 - se eu não mover o mouse, ele carrega a CPU 3-4%.
se o mouse está se movendo rápido - 11-14% de carga
Quero dizer que a fila de mensagens em Win sempre precisa ser processada, mas são ciclos extras da CPU - google "janela C++" - qualquer manual para escrever aplicações de janelas em C++ usando WinAPI, leia lá sobre o gerenciador de mensagens
não ilustrativo.
de uma máquina virtual sob Win7 - se você não mover o mouse, 3-4% de carga na CPU
se o mouse está se movendo rápido - 11-14% de carga de CPU
Quero dizer que a fila de mensagens em Win sempre precisa ser processada e são necessários ciclos extras de CPU - google "c++ windows window".
Para colocar em números mais claros, não estou fazendo nada - 10-15 flutua, 17-30 ao mover-se.
Mas se isso fizer com que o OnTimer desacelere 2 vezes, não, é claro, a menos que com 95-99% de carga.
Qualquer manual de aplicação de janela do Windows em C++ usando WinAPI, leia lá sobre o gerenciador de mensagens
Mas se isso fizer com que o OnTimer abrande duas vezes, não, é claro, exceto para 95-99% de carga.
O timer também é um evento WinAPI, mas duvido que cada programa MQL subscreva o timer do sistema - ele imita o ambiente MQL(máquina virtual)
O manipulador de mensagens aceita compartilhamento de CPU e assim por diante, só não é usado quando não há fila de espera. Para processos MT não deve haver corte de tempo de CPU nesta carga.
Há sempre uma fila em uma janela ativa. É uma fila comum de folhas de café. Adivinhe como esta fila é distribuída pelo terminal entre gráficos e depois entre os programas MQL.
bem, no final - para obter um modo monopólio e não processar mensagens - não há muitas opções, a primeira que vem - aplicação exclusiva em modo tela cheia, mas essa é outra história, como se fosse a "batalha por recursos PC", então você só precisa de uma API para ir até a troca e escrever sua aplicação, e lá registrar a janela ou não
ok, não estou interessado em procurar por pico de carga de CPU - desde que estejamos em Vin, tudo pode acontecer, geralmente estou bem com isso
O timer também é um evento WinAPI, mas duvido que cada programa MQL subscreva o timer do sistema - ele imita o ambiente MQL(máquina virtual)
não é um fato. se você se lembra que havia um bug com timer e número de manipuladores no terminal, indiretamente sugere que cada timer no MT pode muito bem ser um jogo de vinho do sistema