Em geral, todos os testes mostram que os bitmaps são, de alguma forma, mais lentos.
+ Tenho as minhas dúvidas sobre a correcção de ter de ler a coordenada do marcador. porquê verificar o transportador?
Na verdade, os testes mostram que não é mais lento. Pelo menos não nas CPUs modernas.
Aqui está o meu resultado em i7-3770S, Windows 8 x64, 16 RAM, NVIDIA GeForce GT 640M:
2013.04.2722:21:50 BenchmarkLabel (EURUSD,M15) Тестирование завершено
2013.04.2722:21:50 BenchmarkLabel (EURUSD,M15) 5. Время обновления текста и позиций у битмапа без прозрачности = 15007 ms
2013.04.2722:21:35 BenchmarkLabel (EURUSD,M15) 4. Время обновления текста и позиций у битмапа с прозрачностью = 15257 ms
2013.04.2722:21:20 BenchmarkLabel (EURUSD,M15) 3. Время обновления текста и позиций у меток со чтением = 16739 ms
2013.04.2722:21:03 BenchmarkLabel (EURUSD,M15) 2. Время обновления текста и позиций у меток без чтения = 18845 ms
2013.04.2722:20:44 BenchmarkLabel (EURUSD,M15) 1. Время обновления текста у меток без чтения = 21497 ms
2013.04.2722:20:23 BenchmarkLabel (EURUSD,M15) 0. Время разогрева динамических очередей без визуализации = 124 ms
2013.04.2722:20:23 BenchmarkLabel (EURUSD,M15) Для корректного теста подберите размер окна 1024 x 768 пикселей, без индикаторов, не трогайте ничего, не сворачивайте и не закрывайте окна
2013.04.2722:20:23 BenchmarkLabel (EURUSD,M15) Разрешение чарта: 1020 x 761 пикселей
Bitmap tem 15,257ms com todas as transparências vs 21,497ms para etiquetas.
As verificações de condutas são importantes porque o trabalho no mundo real envolve muitas vezes a leitura de parâmetros de objectos antes de os alterar. E quanto mais frequentemente houver mistura de leitura/escrita nos objectos, mais lenta será a modificação do objecto. A melhor estratégia para modificar os objectos é primeiro ler em massa e depois escrever em massa, evitando misturar. Especialmente se tiver milhares de objectos na tabela.
O resultado mais importante do teste é que não há múltiplos, dez ou cinquenta vezes o atraso em bitmaps. Mesmo que possa haver um atraso como nas medições acima (mas há questões sobre o tamanho e a configuração do gráfico de trabalho), estas estão dentro de uma dúzia de por cento.
Mas com tudo isso um bitmap tem uma enorme perspectiva sobre a velocidade com mais objectos, maior qualidade de renderização (incluindo transparência) e a capacidade de renderizar o que se quiser.
Mas eu desenharia gráficos com um bitmap. pois não há opções :) também tabelas multi-objecto.
Um bitmap tem tantas vantagens como os objectos.
Concordo. Cada componente é bom para a sua finalidade. Os bitmaps são indispensáveis, por exemplo, para desenhar elementos de interface. Bem, não há outras opções.
Mas é mais rápido/eficiente produzir as estatísticas com etiquetas. :)
Mas... Como pode ver, embora os números de referência absolutos sejam mais baixos, os seus valores relativos serão +/- os mesmos.
Especifiquei propositadamente as condições de entrada, para que não haja erros aleatórios e para que todos compreendam os requisitos de medição limpa.
O seu resultado com 2355ms num dos testes foi causado por esconder/esconder/desconder/deslizar/trocar a janela terminal durante o teste:
2013.04.2720:09:37 BenchmarkObjects (EURUSD,M5) 5. Время обновления текста и позиций у битмапа без прозрачности = 12558 ms
2013.04.2720:09:24 BenchmarkObjects (EURUSD,M5) 4. Время обновления текста и позиций у битмапа с прозрачностью = 12839 ms
2013.04.2720:09:11 BenchmarkObjects (EURUSD,M5) 3. Время обновления текста и позиций у меток с чтением = 2355 ms
2013.04.2720:09:09 BenchmarkObjects (EURUSD,M5) 2. Время обновления текста и позиций у меток без чтения = 10655 ms
2013.04.2720:08:58 BenchmarkObjects (EURUSD,M5) 1. Время обновления текста у меток без чтения = 10359 ms
2013.04.2720:08:48 BenchmarkObjects (EURUSD,M5) 0. Время разогрева динамических очередей без визуализации = 124 ms
Pode ficar surpreendido, mas este teste (#3) não funciona para mim. Escrevi para o SD(#732578). Mais precisamente, passa num caso em cada dúzia. Sem notificações ou erros no registo. O terminal apenas fica pendurado durante a duração deste teste.
voix_kas: Pode ficar surpreendido, mas este teste (#3) não funciona para mim. Escrevi para o SD(#732578). Mais precisamente, passa num caso em cada dúzia. Sem notificações ou erros no registo. O terminal apenas fica pendurado durante algum tempo ao passar este teste.
Note como algum componente do computador fez com que o desempenho da manipulação de objectos mistos caísse por um factor de 3(teste sanyooooook):
:
Muito provavelmente a culpa é da CPU (os bloqueios mataram-na?) e da memória. Interessante saber que processador foi utilizado.
Ou talvez o computador estivesse apenas a ser stressado ou o ecrã estivesse a ser sacudido na altura deste teste.
Durante o primeiro teste, mudei a janela, durante o segundo não toquei em nada, ao mesmo tempo que o MT4 está a correr nele um guião está a correr um gráfico e alguns outros processos que podem carregar o computador )
Para login e uso do site MQL5.com, você deve ativar o uso de cookies.
Ative esta opção no seu navegador, caso contrário você não poderá fazer login.
Você entrou na conta. A autenticação de dois fatores foi desativada. Configure-a novamente e escaneie um novo código QR ou continue com a autenticação de dois fatores desativada.
Lançado um teste actualizado. Mostra agora a resolução utilizada e com uma dica sobre como testar.
Em geral, todos os testes mostram que os bitmaps são, de alguma forma, mais lentos.
+ Tenho as minhas dúvidas sobre a correcção de ter de ler a coordenada do marcador. porquê verificar o transportador?
Na verdade, os testes mostram que não é mais lento. Pelo menos não nas CPUs modernas.
Aqui está o meu resultado em i7-3770S, Windows 8 x64, 16 RAM, NVIDIA GeForce GT 640M:
Bitmap tem 15,257ms com todas as transparências vs 21,497ms para etiquetas.
As verificações de condutas são importantes porque o trabalho no mundo real envolve muitas vezes a leitura de parâmetros de objectos antes de os alterar. E quanto mais frequentemente houver mistura de leitura/escrita nos objectos, mais lenta será a modificação do objecto. A melhor estratégia para modificar os objectos é primeiro ler em massa e depois escrever em massa, evitando misturar. Especialmente se tiver milhares de objectos na tabela.
O resultado mais importante do teste é que não há múltiplos, dez ou cinquenta vezes o atraso em bitmaps. Mesmo que possa haver um atraso como nas medições acima (mas há questões sobre o tamanho e a configuração do gráfico de trabalho), estas estão dentro de uma dúzia de por cento.
Mas com tudo isso um bitmap tem uma enorme perspectiva sobre a velocidade com mais objectos, maior qualidade de renderização (incluindo transparência) e a capacidade de renderizar o que se quiser.
Pode ser ainda mais rápido:
1. Reduzir a janela do gráfico para que a tela criada cubra ~100% da mesma.
2. Definir um esquema de cores monocromático (através de propriedades -> cores -> esquema de cores)/.
3. Reduzir a escala do gráfico ao mínimo (velas no tamanho máximo).
Mas... Como pode ver, embora os números absolutos da referência sejam mais baixos, os seus valores relativos serão +/- os mesmos.
Note como algum componente do computador fez com que o desempenho da manipulação de objectos mistos caísse por um factor de 3(teste sanyooooook):
Muito provavelmente a culpa é da CPU (os bloqueios mataram-na?) e da memória. Interessante saber que processador foi utilizado.
Ou talvez o computador estivesse apenas a ser stressado ou o ecrã estivesse a ser sacudido na altura deste teste.
Mas eu desenharia gráficos com um bitmap. pois não há opções :) também tabelas multi-objecto.
Um bitmap tem tantas vantagens como os objectos.
Concordo. Cada componente é bom para a sua finalidade. Os bitmaps são indispensáveis, por exemplo, para desenhar elementos de interface. Bem, não há outras opções.
Mas é mais rápido/eficiente produzir as estatísticas com etiquetas. :)
Mas... Como pode ver, embora os números de referência absolutos sejam mais baixos, os seus valores relativos serão +/- os mesmos.
Especifiquei propositadamente as condições de entrada, para que não haja erros aleatórios e para que todos compreendam os requisitos de medição limpa.
O seu resultado com 2355ms num dos testes foi causado por esconder/esconder/desconder/deslizar/trocar a janela terminal durante o teste:
O meu teste de mesa
Sim, Renat, que resolução escolheu. Demorei algum tempo a encontrar tudo no ecrã depois de 1920 x 1080. Vou agora correr no meu portátil.Obrigado pelos resultados. Os bitmaps também estão a ficar mais rápidos.
Pode ficar surpreendido, mas este teste (#3) não funciona para mim. Escrevi para o SD(#732578). Mais precisamente, passa num caso em cada dúzia. Sem notificações ou erros no registo. O terminal apenas fica pendurado durante algum tempo ao passar este teste.
Note como algum componente do computador fez com que o desempenho da manipulação de objectos mistos caísse por um factor de 3(teste sanyooooook):
:
Muito provavelmente a culpa é da CPU (os bloqueios mataram-na?) e da memória. Interessante saber que processador foi utilizado.
Ou talvez o computador estivesse apenas a ser stressado ou o ecrã estivesse a ser sacudido na altura deste teste.
Durante o primeiro teste, mudei a janela, durante o segundo não toquei em nada, ao mesmo tempo que o MT4 está a correr nele um guião está a correr um gráfico e alguns outros processos que podem carregar o computador )