Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

comm: per-line get_flag lookups and allocation in the main loop

Cerrado Apto para principiantes
  • ¿Algo no está bien?
#15,046 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
78/100
Tipo de issue
Refactorización
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust
Área
cli, performance

Línea de trabajo

Comienza en src/uu/comm/src/comm.rs, centrándote en el bucle principal alrededor de las líneas 227, 242 y 258, y en OrderChecker::verify_order alrededor de las líneas 134, 139 y 153. Ejecuta el benchmark proporcionado de seq y comm con y sin --nocheck-order, y después ejecuta las pruebas existentes. Se considera terminado cuando se reduzcan las búsquedas y la asignación por línea, mientras la salida siga siendo idéntica byte a byte y mejore el rendimiento.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

U - comm

In comm, the main loop calls opts.get_flag(options::COLUMN_1/2/3) on every line (lines 227, 242 and 258 of src/uu/comm/src/comm.rs) which is a clap lookup by string.
OrderChecker::verify_order also does self.last_line = current_line.to_vec() on every line (lines 134, 139 and 153), so each line allocates.

Setup: Debian 13, aarch64 (Docker VM), LC_ALL=C, release build of main at 070d78da1 (LTO off), GNU coreutils 9.7.

How to reproduce:

seq -f 'k%08.0f' 1 2 2000000 > ca
seq -f 'k%08.0f' 1 3 3000000 > cb
LC_ALL=C comm -123 ca cb

Time, median of 9 runs:

GNU 9.7 main patched
comm ca cb > file 101 ms 197 ms 117 ms
comm -123 ca cb 67 ms 159 ms 85 ms
comm --nocheck-order -123 ca cb 60 ms 99 ms 67 ms

With --nocheck-order the order checker never runs so only the flag lookups differ. The number of write calls is identical before & after, so the output side is not the cause.

My patch hoists the three flags out of the loop and reuses the buffer (clear() + extend_from_slice). It's 25 lines, byte-identical to GNU's output and the existing tests pass.

For transparency, I noticed this issue thanks to an LLM.

Lenguaje dominante
Rust
Estrellas
24.3k
Forks
2.1k
Merge medio
1 d 16 h
PR fusionados (30 d)
310

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de uutils/coreutils

Todos los issues de uutils/coreutils

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.