Rendimiento real: el cuello está en la travesía

La frase que circula sobre este montaje —SQLite sobre OPFS corre a velocidad casi nativa— es cierta y es engañosa a la vez, y la distancia entre ambas cosas es el contenido de esta lección. Es cierta porque el motor, compilado a WebAssembly y hablando con el manejador síncrono, hace su trabajo en el mismo orden de magnitud que haría sobre un disco de verdad. Y es engañosa porque casi nadie mide el motor: mide el tiempo que tarda una tabla en aparecer en la pantalla, que incluye un viaje de ida y vuelta entre hebras, una copia de cada fila del resultado y un ciclo de renderizado. Cuando alguien concluye que SQLite en el navegador es lento, en la enorme mayoría de los casos ha medido la travesía y le ha puesto el nombre del motor.

Tres relojes que no se pueden sumar

Toda medición útil aquí empieza separando tres cosas que se confunden sistemáticamente.

El primer reloj es el motor: planificar la consulta, recorrer el árbol, comparar claves. Es puro cálculo dentro de WebAssembly, sin entrada ni salida, y es la parte que corre a velocidad casi nativa —el sobrecoste frente al mismo binario compilado a código máquina es un factor pequeño, no un orden de magnitud—.

El segundo es la entrada y salida: cada página que el pager no tiene en su caché se pide al manejador síncrono. Una lectura de una página está en el orden de las decenas de microsegundos, y no depende del tamaño de la base sino del número de páginas que la consulta toque. Aquí un índice ausente no cuesta un poco más: cuesta leer el fichero entero por el mismo canal.

El tercero es la travesía: sacar el resultado del worker y llevarlo a la hebra que dibuja. Es un viaje de mensajes más el clonado estructurado de cada objeto que cruza, y su coste no tiene nada que ver con los dos anteriores. El nivel 10 ya lo midió; lo que cambia aquí es que ahora hay un motor detrás que puede producir cien mil filas en un abrir y cerrar de ojos y ahogar el canal con ellas.

flowchart LR
A[Consulta] --> B[Motor: planifica y recorre]
B --> C[Pager: pide paginas]
C --> D[Manejador sincrono en OPFS]
D --> C
B --> E[Resultado en el worker]
E --> F[Clonado estructurado]
F --> G[Hebra principal]
style B fill:#a6e3a1,color:#11111b
style D fill:#89b4fa,color:#11111b
style F fill:#f38ba8,color:#11111b

Sumar los tres relojes en una sola cifra es lo que produce diagnósticos falsos. Una consulta que el motor resuelve en un tiempo indistinguible de cero puede tardar decenas de milisegundos en llegar a la pantalla, y en ese caso reescribir el SQL no sirve absolutamente de nada.

La proporción entre los tres es lo que hay que interiorizar, y es más desequilibrada de lo que la intuición sugiere. El primero y el segundo comparten orden de magnitud —microsegundos, decenas de microsegundos— porque ambos ocurren dentro de la misma hebra sin salir de ella. El tercero vive en otro régimen: hay un mensaje que atraviesa una frontera entre contextos de ejecución, un algoritmo de copia que recorre cada objeto del resultado y un turno del bucle de eventos que hay que esperar. No es que sea un poco más caro; es que se mide con otra unidad.

El cuello es la travesía, no el motor

La regla operativa que se deriva de lo anterior cabe en una línea: el coste no lo marca el tamaño del trabajo sino el número de cruces. Una aplicación que ejecuta mil consultas pequeñas desde la hebra principal paga mil viajes; la misma aplicación que ejecuta una consulta que devuelve lo mismo agregado paga uno. La diferencia entre ambas versiones suele ser de dos órdenes de magnitud, y ninguna de las dos ha cambiado una coma del motor.

De ahí salen tres patrones que valen más que cualquier ajuste.

El cuarto patrón merece una demostración porque el cambio de escala que produce no es incremental. Miles de inserciones sueltas ejecutan miles de transacciones, y cada transacción implica crear el journal, escribirlo, sincronizar, confirmar y borrarlo. Envueltas en una sola, todo ese protocolo se paga una vez.

// La misma cantidad de datos, dos ordenes de magnitud de diferencia
const stmt = db.prepare("insert into eventos (dia, tipo, carga) values (?,?,?)");
db.exec("BEGIN");
try {
  for (const e of lote) stmt.bind([e.dia, e.tipo, e.carga]).stepReset();
  db.exec("COMMIT");
} catch (err) {
  db.exec("ROLLBACK");
  throw err;
} finally {
  stmt.finalize();
}

Fíjate en que la sentencia se prepara una vez y se reutiliza reiniciándola, en lugar de compilarse en cada vuelta. Eso ahorra el trabajo del planificador por cada fila, que es pequeño pero real, y sobre todo mantiene el bloqueo del fichero tomado el mínimo tiempo posible, que es la otra mitad del problema. Reiniciar es además obligatorio por lo que viste en la lección anterior: una sentencia a medio consumir mantiene la base bloqueada.

Sobre el motor propiamente dicho hay pocas diferencias que rascar entre los VFS, pero las que hay están documentadas y son coherentes con la lección uno. El VFS de conjunto de manejadores reservados es, con diferencia, el más rápido de los tres, y la razón es estructural: no tiene puente. Cada operación de fichero ocurre dentro de la misma hebra, sin dejar una petición en un búfer compartido ni dormirse esperando respuesta. La documentación es precisa sobre dónde se nota: en una interacción humana —modificar una entrada de una agenda— la diferencia es imperceptible; en operaciones por lotes es descarada. Entre el VFS con puente y su variante con bloqueos del navegador no hay ganador claro: las mediciones varían más entre dispositivos y entre ejecuciones que entre las dos implementaciones.

Bases de varios gigabytes

Aquí es donde el montaje deja de parecer un truco. Una base de varios gigabytes dentro del navegador es hoy un caso soportado, no una hazaña, y la razón es que el pager nunca lee el fichero entero: lee las páginas que la consulta toca. Una consulta por índice sobre una tabla de cincuenta millones de filas toca unas pocas decenas de páginas, y su coste es prácticamente independiente del tamaño total. El comportamiento a esa escala es exactamente el mismo que fuera del navegador, con las mismas reglas: el índice correcto lo cambia todo, el recorrido completo de tabla es proporcional al fichero, y las estadísticas del planificador merecen mantenerse.

Lo que sí es distinto, y es el techo que conviene conocer antes de llegar a él, es la memoria. La compilación es de treinta y dos bits, de modo que el espacio de direcciones de su montón lineal está acotado en cuatro gigabytes, y en la práctica el navegador concede bastante menos. Esa limitación no afecta al tamaño del fichero, que vive en OPFS y se lee por páginas, pero sí afecta a todo lo que el motor necesite tener en memoria a la vez: la caché de páginas, los resultados intermedios de una ordenación, una tabla temporal, y por supuesto el conjunto de filas que estés a punto de hacer cruzar la frontera.

-- El tamano de pagina se fija al crear la base y no despues
PRAGMA page_size = 8192;

-- Cache en kibibytes cuando el valor es negativo. Elige a sabiendas
PRAGMA cache_size = -32000;

-- Que los temporales no salgan a fichero si no hace falta
PRAGMA temp_store = MEMORY;

Ese último ajuste tiene un efecto lateral que enlaza con la lección uno: los ficheros temporales del motor ocupan plaza en el conjunto de manejadores reservados igual que las bases y los journals, y una ordenación grande que decida escribir a disco puede agotar la capacidad del pool. Si trabajas con ese VFS y con bases grandes, dimensionar la capacidad y decidir dónde viven los temporales dejan de ser detalles.

A esa escala reaparecen además todas las herramientas clásicas del oficio, sin adaptación ninguna. El plan de ejecución sigue siendo la primera parada ante una consulta lenta, y sigue diciendo la verdad: si aparece un recorrido completo de tabla donde esperabas un índice, has encontrado el problema y no está en el navegador. Mantener actualizadas las estadísticas del planificador importa aquí más que en un servidor, porque cada página que decide leer de más pasa por el manejador síncrono y compite por el bloqueo con el resto de tu aplicación.

-- El diagnostico no cambia porque el disco sea un navegador
EXPLAIN QUERY PLAN
SELECT tipo, count(*) FROM eventos WHERE dia BETWEEN ? AND ? GROUP BY tipo;

ANALYZE;  -- estadisticas frescas para el planificador

Medir en lugar de creer

Ninguna de las cifras de esta lección debe entrar en tu proyecto sin comprobarse, porque dependen del dispositivo, del navegador y de la versión, y porque el reparto entre los tres relojes es distinto en cada aplicación. Lo que sí es transferible es el método: instrumenta los tres tramos por separado y mira cuál domina antes de tocar nada.

// Dentro del worker: separa el motor de la travesia
const t0 = performance.now();
const filas = db.selectObjects("select * from eventos where dia = ?", [dia]);
const t1 = performance.now();
postMessage({ filas, motor: t1 - t0, enviado: performance.now() });

// En la hebra principal: el tercer tramo se mide al recibir
worker.onmessage = (e) => {
  const travesia = performance.now() - e.data.enviado;
  console.log("motor", e.data.motor, "travesia", travesia, "filas", e.data.filas.length);
};

Dos cautelas más para que la medición valga algo. La primera: mide siempre en frío y en caliente por separado, porque la caché de páginas del pager cambia el resultado por completo entre la primera ejecución y la segunda, y ambos números son reales para casos distintos. La segunda: mide con el volumen de datos que vas a tener, no con el que tienes hoy. Casi todos los diseños que se caen a los cinco gigabytes se veían perfectos con cinco megabytes, y el punto en el que dejan de funcionar nunca es el que uno espera.