Compilar Rust a WebAssembly con información de depuración completa puede resultar hasta 40 veces más lento de lo esperado. Un caso concreto: un programa mínimo de 40 líneas pasa de 1,5 segundos sin depuración a 50 segundos al activar debug = 2 (DWARF completo), el ajuste por defecto del perfil dev de Rust. La raíz del problema está en el pase "Register Stackify" del backend de LLVM para WebAssembly.
WebAssembly es una máquina de pila, así que LLVM primero genera código con registros temporales y luego una fase mueve los valores que puede directamente a la pila del wasm, ahorrando código y trabajo en tiempo de ejecución. Pero mover una instrucción obliga a mover o actualizar también sus registros DBG_VALUE, que indican al depurador dónde vive cada variable.
Con debug = 2, el inlining agresivo genera cientos de miles de DBG_VALUE por función. Register Stackify hace recorridos lineales repetidos sobre una lista que ella misma agranda al insertar definiciones hundidas con sus registros vaciados, y al copiar valores baratos genera registros frescos en cada uso. El resultado es un comportamiento cuadrático que vuelve el pase dolorosamente lento.
El bug ya se reportó contra clang (llvm-project #168326) y se cerró en marzo de 2026 con un parche que cuenta los usos del registro y detiene el recorrido al hallarlos. Sin embargo, el arreglo es incompleto para Rust: tras varias copias, un DBG_VALUE puede quedar por encima de la definición y nunca ser alcanzado por un recorrido hacia delante, así que el contador nunca llega a cero.
El autor propone un parche propio con tres cambios: detener el recorrido ascendente y descendente de forma independiente, evitar búsquedas innecesarias en la tabla hash de variables y saltarse las búsquedas de número de posición para los registros de depuración. Las primeras pruebas reducen las búsquedas en tabla hash de 27,4 millones a 3 millones.