El desarrollador de scc, una herramienta para contar líneas de código, detectó cuellos de botella internos al comparar su rendimiento con mezura, otro contador más reciente. Las pruebas con hyperfine sobre el árbol de fuentes del kernel Linux mostraron que mezura completaba el trabajo 2,56 veces más rápido (unos 204 ms frente a 509 ms en scc), pese a que scc procesaba aproximadamente un 28 % más de archivos.
Para localizar el origen de la diferencia recurrió a strace y comparó las llamadas al sistema de ambas herramientas. En scc destacaban cuatro focos: alrededor de 134.000 llamadas futex (síntoma de bloqueos por hilos en espera), 95.897 fallos en epoll_ctl casi uno por archivo, 383.594 fcntl (cuatro por fichero) y 286.428 newfstatat (tres estadísticas por archivo).
El primer arreglo fue ampliar el número de goroutines en la etapa de stat de archivos, que estaba limitada a una, lo que provocaba que la cola de potenciales archivos se llenara y la cola de procesamiento quedara vacía. Esa modificación redujo las llamadas futex a unas 5.500 y recortó unos 160 ms el tiempo total.
El segundo frente es el coste de os.Open, que en Linux entrega el descriptor al poller del runtime de Go, generando fcntl y epoll_ctl extra. Como ejemplo se incluye un programa mínimo que demuestra el comportamiento: con syscall.Open directo desaparecen las llamadas innecesarias al kernel. El artículo describe la arquitectura interna de scc (walker, colas y etapas de procesamiento) y señala que estos ajustes deberían acercar su rendimiento al de mezura.