Go escrito con mentalidad de C

Experimento: el mismo generador de tickets ESC/POS escrito en Go de dos formas, midiendo el resultado (i9-9900K, Go 1.26, 30 líneas por ticket). Las dos versiones producen exactamente los mismos bytes.

	ns/ticket	bytes reservados/ticket	reservas/ticket
Hábitos de JS (`+=` en strings, `fmt.Sprintf`, `[]*Item`)	~9.600	14.378	126
Hábitos de C (un buffer reutilizado, `strconv.Append*`)	~550	0	0

Por qué

Los strings son inmutables. s += x crea un string nuevo y copia todo lo anterior en él. En un bucle, cada iteración copia más bytes que la anterior: el coste crece con el cuadrado del tamaño.
fmt.Sprintf reserva memoria para el resultado y usa reflexión. strconv.AppendInt escribe directamente en tu buffer.
Reutilizar el buffer: buf = buf[:0] pone la longitud a 0 pero conserva la capacidad, es decir, la memoria ya reservada. Tras el primer ticket no se vuelve a reservar nada. Es lo que hará el buffer de la fase 2.

Padding: el orden de los campos cambia el tamaño

El procesador exige que un int64 empiece en una dirección múltiplo de 8. El compilador rellena con huecos (padding) para cumplirlo:

{bool, int64, bool, int64, bool} ocupa 40 bytes.
{int64, int64, bool, bool, bool} ocupa 24 bytes.

Con un millón de elementos son 38 MB frente a 22 MB. En C pasa exactamente lo mismo.

Un slice es `{puntero, longitud, capacidad}`

header := make([]byte, 0, 16)
header = append(header, 0x1b, '@')
a := append(header, 'A')
b := append(header, 'B')   // a también termina en 'B'

Hay capacidad libre, así que append no copia: escribe en el mismo array. a y b comparten memoria. Quien piensa en punteros lo ve venir; quien piensa en arrays de JS, no.

Dinero en `float64`

10 × 0.10 da 0.9999999999999999. El number de JS es un float64. Para dinero se usan enteros en céntimos.

El precio de la versión rápida

BuildTicket devuelve una vista del buffer interno, que deja de ser válida en la siguiente llamada. Hay que documentar quién es el dueño de esa memoria. Es exactamente la regla de la API de la librería: documentar en cada función quién es dueño de cada puntero.

Tercera versión: una IA a partir de una spec escueta

Spec: "cabecera en negrita, una línea por producto, total, corte, precios con dos decimales, tests". El código resultante es idiomático (bytes.Buffer, fmt.Fprintf, dinero en céntimos) y pasa todos los criterios de aceptación.

	ns/ticket	bytes/ticket	reservas/ticket
IA con spec escueta	~8.300	3.186	99

Casos que la spec no menciona:

Caso	IA	Estilo C	Estilo JS
Descuento de −1,50	`-1.-50` ❌	`-1.+0` ❌	`-1.50` ✅ (de casualidad)
`é`, `ñ`, `€`	UTF-8 ❌	UTF-8 ❌	UTF-8 ❌
Nombre más largo que el papel (48/32 columnas)	no lo trata	no lo trata	no lo trata

Negativos: en Go (y en C) el resto de un número negativo es negativo: -150 % 100 == -50. Las versiones con enteros lo formatean mal.
Codificación: la impresora no entiende UTF-8. é se envía como C3 A9 y en papel sale como dos símbolos extraños. Hay que convertir a la página de códigos de la impresora (fase 6).

Conclusión: el resultado nunca es mejor que la spec más la capacidad de quien lo revisa. Las decisiones que no se piden las toma el modelo "por defecto", y solo las detecta quien sabe que existen. Una spec de experto incluiría: presupuesto de reservas de memoria, quién es dueño del buffer, importes negativos, página de códigos y ancho de línea según el modelo de impresora.

Cuándo no merece la pena

Si el ticket se genera una vez por venta, 9 µs frente a 0,5 µs da igual. La versión rápida compensa en rutas calientes: miles de peticiones por segundo o bucles sobre millones de elementos. Primero se mide (go test -bench -benchmem, pprof) y después se optimiza.

4.0 KiB Raw Blame History Unescape Escape