Cómo evitar el costo de rendimiento del desbordamiento: ¿oculto?

Question

Tengo una tabla HTML que puede tener más de 1K filas y una docena de columnas.

Quiero que las columnas tengan un tamaño fijo (controlable por el usuario) y no crezcan/contraigan ni vertical ni horizontalmente. De manera visual, el contenido de una celda de tabla particular estará en una línea y el desbordamiento se cortará al final de la celda.

Haciendo análisis de rendimiento en Chrome en una gran mesa el principal asesino de rendimiento es desbordamiento: oculto.

He intentado poner el contenido de cada celda dentro de una entrada, ya que eso replicaría el mismo comportamiento visual, pero eso tiene un impacto similar en el rendimiento.

¿Qué recomiendan las personas para mejorar el rendimiento?

Si es necesario, no tengo que usar una etiqueta de tabla, pero preferiría seguir con la etiqueta de tabla si se puede lograr un buen rendimiento.

Actualización 1: He incluido un archivo que muestra el problema de rendimiento here. Advierta que el archivo es bastante masivo (25MB) y ralentizará su computadora. De forma predeterminada, la tabla no tiene el desbordamiento establecido en oculto, y una vez que la tabla se ha cargado (puede tomar un tiempo) el rendimiento del navegador es relativamente sencillo.

Sin embargo, si edita el archivo y descomenta las líneas 12-15 y luego lo abre. Verá que después de cargar el navegador alrededor de la mesa es significativamente menos receptivo.

Answer 1

Primero, la cantidad de marcado requerida para tener una tabla es mucho más grande que solo usar divs con clear: ambos css para una nueva fila. así que ese es el primer golpe de rendimiento.

También, se está ajustando el desbordamiento como clase (?)

<style type="text/css"> .ovfl { overflow:hidden; }</style> 

    <td class="ovfl"></td> 

Como acotación al margen, 1000 filas es un peso para entregar.

Con los divs, al menos tiene una oportunidad más fácil para lanzarlos fuera de la vista (más allá del rollo) en un div con pantalla: ninguno hasta que el visitante se desplace hacia ellos.

algunas pieles de gato a su mayoría probablemente en este trabajo,

Esperanza tenían algunos buenos pensamientos.

Answer 2

Podría intentar usar un enfoque en mosaico. Es un enfoque bastante típico para hacer cosas como juegos infinitamente desplazables lateralmente de manera eficiente.

Ponga todos sus datos en una matriz Javascript, y luego tenga N + 1 filas en una tabla que tenga N filas visibles. Cuando te desplazas hacia abajo, el último elemento se moverá a la vista. En el momento en que se haya desplazado lo suficiente para que el primer elemento se salga de la vista, cambiará todos los datos en una fila y restablecerá la posición de desplazamiento en el punto donde comenzó. Hecho correctamente, el cambio sería completamente transparente para el usuario. Solo trabajará con N + 1 filas en una tabla N-rows-visible.

He hecho esto antes, pero bajo restricciones de IU muy específicas. Me quedo como un obturador ante la idea de hacer que esto sea consistente usando las barras de desplazamiento incorporadas en el navegador y demás.

Answer 3

FYI: Me he encontrado con este problema en el iPad/iOS que causa problemas de rendimiento con una página que tiene alrededor de cien filas en una tabla con table-layout: fixed.

Tan pronto como una celda, o un div en una celda, obtiene un atributo que obliga a la celda a dibujarse individualmente, toma aproximadamente 300ms en vez de 100ms dibujar (lo que hace que la IU se sienta abismalmente lenta para mi situación).

Cualquiera de las dos propiedades (position:relative o overflow:hidden) me causó el problema, eliminarlas optimizó la velocidad pero provocó el desbordamiento de texto si el texto de la celda era demasiado ancho para las columnas de ancho fijo.

La ralentización estaba sucediendo incluso después de que se dibujaron las tablas, porque estoy apareciendo dinámicamente un div absoluto sobre la mesa. Al perfilar el javascript (usando (new Date).getTime()), la ralentización se mide en lugares en el javascript que no tienen nada que ver con la tabla.

[editar: Añadido siguiente como solución parte]

1. Ponga todo el contenido de células dentro de un elemento span (lo que puede medir offsetWidth de contenido en lugar de anchura de que contiene elemento de bloque).
2. Después de agregar la fila en el documento, pruebe si cada span.offsetWidth es mayor que el ancho de la columna, de ser así agregue el "overflow: hidden" al estilo (oa través de una clase) del bloque contenedor.
3. Puede omitir 1 y 2 arriba para algunas columnas (si se sabe que el contenido de la celda nunca necesitará recorte).

Advertencias:

1. mediciones sólo hechas para IOS5 Safari (que no el perfil cualquier otro navegador).
2. Funciona para nosotros porque creamos dinámicamente filas de tablas (¿procesar su ejemplo con javascript sería lento?).
3. La mayoría de las celdas de nuestros datos no se desbordan (el recorte solo se requiere escasamente, solo un número limitado de celdas).
4. Carga de la página inicial comprometida (la generación de la tabla en la página pasó de 80ms a 800ms).
5. Pero aceleró la ventana emergente combinada dinámica (de 340 ms a 130 ms), lo que ofrece una capacidad de respuesta del teclado mucho mejor.

Por su situación, podría ser rápido a la primera usando columnas de ancho variable, medir offsetWidth de todas las columnas, el establecimiento de ancho de las columnas de ancho de píxel y el establecimiento de overflow: hidden sólo en columnas donde offsetWidth de la columna es mayor que el ancho de píxel lo usarás para la columna.

Answer 4

Webkit bug 75001 está relacionado con este problema y cubre el trabajo que se está realizando para resolverlo (también vea las dependencias de bugzilla para obtener información).