Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Me corrijo. El rendimiento de los mapas de bits es inferior al de las etiquetas en un 16%-25%(dependiendo del número de elementos), pero no en un orden de magnitud, como he escrito antes.
Probablemente hubo errores/ineficiencias en el código cuando se aprendió la herramienta por primera vez.
Se adjunta el código.
tol64
Créeme,no tengo ningún motivopara engañarte = a mí mismo. En mi primer experimento observé un mapa de bits en el probador. Por desgracia, no puedo reproducirlo. :(
...
tol64
Créeme,no tengo ningún motivopara engañarte = a mí mismo. En mi primer experimento observé un mapa de bits en el probador. Por desgracia, no puedo reproducirlo. :(
También me gustaría llamar la atención de los desarrolladores sobre las diferencias en la visualización de las fuentes:
A la izquierda está el mapa de bits y a la derecha las etiquetas.El mapa de bits tiene una representación de la fuente ligeramente más atrevida, aunque todos los ajustes son los mismos.
La cuestión no es crítica. Pero para prestar atención. :)
También me gustaría llamar la atención de los desarrolladores sobre las diferencias en la visualización de las fuentes
A la izquierda está el mapa de bits, a la derecha las etiquetas.El mapa de bits tiene una representación de la fuente ligeramente más audaz, aunque todos los ajustes son los mismos.
La cuestión no es crítica. Pero para el orden es necesario prestar atención. :)
Me corrijo. El rendimiento de los mapas de bits es inferior al de las etiquetas en un 16%-25%(dependiendo del número de elementos), pero no en un orden de magnitud, como he escrito antes.
No. Sin embargo, su prueba es incorrecta.
Se utiliza ChartRedraw después de cada cambio. Así que, de hecho, está probando 10000 veces ChartRedraw. Esto no está bien.
La tarea consiste en averiguar qué cambia más rápido: las etiquetas o los mapas de bits. Y no su producción posterior en el gráfico.
Aquí están los resultados de la prueba si se deja ChartRedraw dentro de un bucle.
Tiempo de actualización del mapa de bits = 40980.
Hora de actualizar las etiquetas = 41777.
(es decir, el mapa de bits es incluso ligeramente más rápido que las etiquetas).
Y quiero que note, que el número de etiquetas y el ancho del mapa de bits en presencia de ChartRedraw dentro de un bucle - no afecta a nada. Por lo tanto, la función ChartRedraw es la más lenta en esta situación.
---
Si elimina ChartRedraw del bucle, obtendrá números completamente diferentes
Tiempo de actualización del mapa de bits = 5788.
Hora de actualización de las etiquetas = 234.
por lo que el terminal con las etiquetas es 20 veces más rápido que el mapa de bits
y aquí, por supuesto, ya podemos ver la dependencia de la altura del mapa de bits. para 100 marcas:
Tiempo de actualización del mapa de bits = 51355.
Tiempo de actualización de las etiquetas = 1108.
50 veces la diferencia
y aquí hay un mapa de bits con tamaño 250*20. es decir, no cambiar las coordenadas de las marcas.
obtenemos
Tiempo de actualización del mapa de bits = 25054.
La diferencia con las cien marcas es de 25 veces.
Así que, como puedes ver, el mapa de bits es realmente lento en lo que se refiere a trabajar con él.
inequívocamente, que el trabajo cíclico constante con arrays + WinGdi TextOut + creación de ResourceCreate = inferior a los objetos nativos de MT por al menos un orden, o incluso 50 veces.
Por ello, no debes rechazar los objetos MT. Como probablemente será muy conveniente para dibujar gráficos e histogramas.
¿Y qué bandera para establecer el grosor de la fuente utilizaste para el mapa de bits?
El valor por defecto es 0, no lo pongo explícitamente. Puedes verlo en el código fuente adjunto.
El "juego" adicional con diferentes banderas tampoco condujo a la uniformidad.
...
El objetivo es averiguar si las etiquetas o los mapas de bits se modifican más rápido. No su posterior salida a la carta.
...
La eliminación de la función ChartRedraw() del bucle es incorrecta, porque la "operación atómica" de modificación de la propiedad de la etiqueta de texto no es manejada de ninguna manera por el videomotor del terminal.
Sólo cuando se llama a ChartRedraw() se dibuja toda la ventana, incluyendo la superposición mutua de imágenes del canal alfa de diferentes objetos.
Esta hipótesis está estrictamente confirmada por el perfilador de código en el script con etiquetas de texto.
En cuanto al mapa de bits, el cuello de botella es la función TextOut().
...
En cuanto al mapa de bits, el cuello de botella es la función TextOut().
Eso está más claro: ))
Esa es la forma de hacerlo más claro: ))
Estoy de acuerdo. :)
...
Aquí están los resultados de la prueba si se deja ChartRedraw dentro del bucle.
Tiempo de actualización del mapa de bits = 40980.
Tiempo de actualización de las etiquetas = 41777.
(es decir, el mapa de bits es incluso ligeramente más rápido que las etiquetas)
Es extraño, yo tengo la imagen contraria:
Es mejor no usar Argb_normalize, ya que da un coste extra por la normalización del color. Es mejor pintar las cosas sencillas con colores puros.
También la velocidad está directa y fuertemente influenciada por la tarjeta de vídeo, ya que estamos aprovechando al máximo sus características 2D. Por ejemplo, en portátiles poco potentes con tarjetas gráficas rudimentarias , el renderizado es lento y la diferencia en los métodos de salida es grande.