Como otros, he seguido este camino:
- Empieza con una lista, quizás descargada de un repositorio actual de GitHub.
- Inmediatamente se topa con el límite de 2000 entradas.
- ¡Oh, puedo usar Regex, es genial!
- Las expresiones regulares complejas superan fácilmente los 100 caracteres.
- Divídelas.
- Refina una expresión regular, ¡ups, también superó los 100 caracteres!
- Divídela aún más.
Lidiar con los límites no es prohibitivo, es simplemente molesto, especialmente cuando los límites son artificiales. Dicho esto, entiendo que este filtrado es síncrono y que el procesamiento extendido puede generar problemas de rendimiento, y aprecio la dificultad de intentar establecer límites que funcionen para la mayor audiencia posible. Así que, aunque lucho con los límites, no puedo discrepar razonablemente con ellos.
Veo el código para el filtrado aquí en word_watcher.rb. Como desarrollador, estaría feliz de intentar escribir un plugin, pero ese código no parece extensible. No tendría idea de cómo conectar JavaScript en un plugin para aumentar los procesos de Ruby… o si eso es posible con la forma en que está escrito el código de word_watcher.
Aquí hay una idea para una mejora que ayude a aliviar parte de la carga de procesar listas extensas.
En lugar de procesar la lista completa para cada tipo de lista de vigilancia, considere un bucle a través de diferentes bloques de filtros. Por ejemplo, podemos poner los filtros más comunes y abusivos en el bloque1 y otros en los bloques2-n. El proceso de filtrado síncrono solo procesará un bloque a la vez y solo realizará un bucle completo a través de todos los filtros en la operación de Guardado final. Los bloques pueden operar sobre listas existentes, por lo que no es necesario que nadie haga un cambio. Las listas existentes se dividirán en bloques de 1000 entradas, por lo que el bloque1 es 1-1000, el bloque2 es 1001-2000, etc. Los administradores que deseen optimizar ahora pueden optar por mover sus filtros de mayor prioridad más arriba en la lista.
Una ventaja de esto es que no es necesario procesar toda la lista para detectar un problema. Los problemas más probables se detectarán con un bloque más pequeño y el proceso síncrono podrá devolver más rápido el procesamiento del bloque más pequeño. Claro, si el texto de vigilancia no se encuentra en el primer bloque, será necesario procesar otro bloque. Eso es una sobrecarga ligeramente mayor para detectar abusos menos probables. Esto se convierte en una cuestión de ajuste opcional, si es que alguien alguna vez se preocupa por hacerlo.
Una opción adicional aquí sería que el Administrador elija el tamaño de los bloques. Al reducir el tamaño de los bloques, tal vez a 500 entradas por ciclo de bucle, cada proceso síncrono será más rápido, pero puede haber más bloques que procesar. Esto depende del tipo de abuso presente y de qué tan bien esté priorizada la lista. Nuevamente, este tipo de ajuste sería opcional y, francamente, dudo que muchos administradores hagan mucha optimización de este tipo.
Tenga en cuenta que el ajuste fino implica que tenemos métricas cuantificables: ¿Cuánto tiempo dedicamos al procesamiento de palabras de vigilancia y cuántos problemas estamos detectando realmente? Esta cantidad de detalle nerd debería dejarse para una mejora posterior o un plugin si realmente es deseable.
En última instancia, si se implementa el “procesamiento de bloques de palabras de vigilancia” como se describe aquí, el número de elementos en la lista se puede extender más allá de 2000. Sí, habrá una sobrecarga al leer listas más largas y dividirlas. Una vez más, si tenemos métricas sobre cuánto tiempo se consume en este proceso, los administradores pueden determinar su propio umbral de optimización… pero dudo que mucha gente se adentre profundamente en esto. La guía publicada podría ser algo como “El límite sigue siendo 2000 palabras de vigilancia sin procesamiento de bloques de palabras de vigilancia. Con el procesamiento de bloques, no hay un límite específico, pero el límite práctico podría estimarse en alrededor de 5000, con una degradación notable del rendimiento que aumenta a medida que aumenta el número de entradas”.
¿Alguna alegría aquí?