Medición de la cantidad de texto y código en mis artículos

En 2017, por pura curiosidad, decidí comprobar qué proporción de mis artículos en el blog era texto escrito y qué parte correspondía a código fuente. En aquel momento, escribí un conciso programa de 21 líneas en Perl que me dio una respuesta rápida.

En 2021—con motivo de unos experimentos con el lenguaje Perl 6 (actualmente Raku)—reescribí dicho script y, para mi sorpresa, obtuve números completamente diferentes. Por falta de tiempo dejé el tema de lado, pero recientemente volví a él para llevar a cabo una investigación exhaustiva.

Resultó que un problema aparentemente trivial—“contar los caracteres de texto y código en una página HTML”—oculta bajo la superficie un fascinante mundo de matices de ingeniería. Desde errores en librerías abiertas de CPAN y sutilezas en el anidamiento del árbol DOM, hasta la especificación de Unicode (grafemas frente a puntos de código) y optimizaciones de rendimiento en la capa de red HTTP.

En este artículo, te guiaré a través de sucesivos intentos para conciliar los resultados en 4 lenguajes de programación (Perl 5, Raku, Python y Rust), presentando estadísticas completas para 68 artículos, gráficos de evolución de la proporción de código y resultados de rendimiento inesperados.

Acto I: El año 2017 y el script de 21 líneas en Perl 5

Mi enfoque inicial en 2017 se basaba en una premisa sencilla: obtener la página principal del blog, extraer los enlaces a los artículos desde los encabezados <h2>, descargar cada publicación individualmente y contar los caracteres en los elementos de texto (<h1>-<h4>, <p>, <li>) frente a los bloques de código (<pre>).

A continuación se muestra el script original utilizando la librería HTML::TagParser:

#!/usr/bin/env perl
use warnings;
use strict;
use HTML::TagParser;

my $url = 'https://gustawdaniel.com';
my @tags = ("h1 h2 h3 h4 li p", "pre");

print "|     text |     code | title \n";

my @list = HTML::TagParser->new( $url )->getElementsByTagName( "h2" );
foreach my $elem ( @list ) {
    my $post = HTML::TagParser->new( $url . $elem->firstChild()->getAttribute( "href" ) );
    my @str = ("", "");
    foreach my $i ( (0, 1) ) {
        my @elements = map { $post->getElementsByTagName($_) } split / /, $tags[$i];
        $str[$i] = join("", map { $_->innerText } @elements);
    }
    printf("| %8d | %8d | %-60s \n", (map { $str[$_] =~ y===c } (0, 1)), $elem->innerText);
}

Funcionó a la perfección… hasta que lo ejecuté de nuevo años más tarde en un entorno moderno y me encontré con dos problemas importantes.

Problema 1: Falta de soporte HTTPS

El primer error al volver a ejecutarlo en un entorno limpio fue:

URI::Fetch failed: Protocol scheme 'https' is not supported (LWP::Protocol::https not installed)

Resultó que HTML::TagParser utiliza internamente LWP::UserAgent. Por defecto en Perl, LWP solo admite http://. La instalación del paquete liblwp-protocol-https-perl (o mediante CPAN: cpanm LWP::Protocol::https) permitió establecer conexiones cifradas.

Problema 2: Anatomía de un error en CPAN (HTML::TagParser)

Tras solucionar HTTPS, el script funcionó, pero para ciertos artículos (por ejemplo, sobre la Ley de Zipf y la Ley de Benford) mostraba exactamente 0 caracteres de código, ¡a pesar de que dichos artículos contenían numerosos bloques <pre>!

La depuración reveló un fallo en el propio módulo HTML::TagParser (HTML/TagParser.pm, línea 257). Al analizar valores de atributos entre comillas dobles ("), el módulo utilizaba una expresión regular que truncaba la cadena del atributo en la primera aparición de… ¡una comilla simple (')!

Las URL de los artículos estaban estructuradas de la siguiente manera:

• /posts/en/zipf's-law-in-nodejs/ $\rightarrow$ se truncaba a /posts/en/zipf
• /posts/en/benford's-law/ $\rightarrow$ se truncaba a /posts/en/benford

Al solicitar esas URL malformadas, el servidor devolvía páginas de error 404 (las cuales no contenían etiquetas <pre>).

La solución rudimentaria en Perl consistió en eludir el método defectuoso de la librería y acceder directamente a la estructura interna del arreglo de nodos de Perl ($node->[0]->[$node->[1]]->[2]), que almacena el texto sin procesar de los atributos HTML:

sub get_href {
    my ($node) = @_;
    my $raw = $node->[0]->[$node->[1]]->[2] // "";
    if ($raw =~ /href=(?:"([^"]+)"|'([^']+)'|([^\s>]+))/i) {
        return $1 // $2 // $3;
    }
    return $node->getAttribute("href");
}

Error de la librería resuelto, pero esto era solo el comienzo de nuestros descubrimientos.

Acto II: La reescritura en Raku y el desafío de anidamiento en el DOM

En 2021, intenté reescribir el algoritmo en Raku. En Raku, en lugar de HTML::TagParser, utilicé el moderno módulo DOM::Tiny con selectores CSS:

#!/usr/bin/env raku
use WWW;
use DOM::Tiny;

my $base_url = 'https://gustawdaniel.com';
my $dom = DOM::Tiny.parse(get($base_url));

for $dom.find('h3 a') -> $a {
    my $url  = $a.attr('href');
    my $post = DOM::Tiny.parse(get($url));

    my $text = $post.find('h1, h2, h3, h4, p, li').map(*.all-text).join;
    my $code = $post.find('pre').map(*.all-text).join;

    printf("| %8d | %8d | %-60s \n", $text.chars, $code.chars, $a.all-text.trim);
}

El código se redujo a solo 18 líneas y resultó sumamente limpio. Sin embargo, durante una auditoría en los 68 artículos del blog, noté discrepancias.

En un artículo antiguo de 2017 (“Application with FOSUserBundle and Google Maps API”), Raku devolvió 42,469 caracteres de código, mientras que otros analizadores indicaban 42,529 caracteres.

¿Por qué faltaban 60 caracteres?

Este artículo contenía 70 bloques de código <pre> con fragmentos de plantillas HTML y Twig. Dentro de algunos de esos bloques <pre> había elementos HTML anidados, como:

<pre class="astro-code"><code><div class="container eternity-form">...</div></code></pre>

El recorrido lineal del árbol en Raku, al no rastrear el contexto del nodo padre, encontraba la etiqueta <div> anidada, “olvidaba” que estaba dentro de un bloque <pre> y contabilizaba ese fragmento de HTML interno como texto del artículo en lugar de código.

La solución fue propagar recursivamente una bandera de contexto $is_pre a lo largo del árbol DOM:

sub collect-text($tree, $is_pre = False) {
    my $t = "";
    my $c = "";
    for $tree.children -> $node {
        if $node ~~ DOM::Tiny::HTML::Text {
            if $is_pre { $c ~= $node.text; } else { $t ~= $node.text; }
        } elsif $node ~~ DOM::Tiny::HTML::Tag {
            my $in_code = $is_pre || $node.tag eq "pre";
            my ($sub_t, $sub_c) = collect-text($node, $in_code);
            $t ~= $sub_t;
            $c ~= $sub_c;
        }
    }
    return ($t, $c);
}

Acto III: Sutilezas en el análisis HTML – Espacios y entidades

Al comparar diferentes librerías de análisis HTML en Python (selectolax), Rust (scraper), Perl 5 (Mojo::DOM) y Raku (DOM::Tiny), descubrí otras diferencias sutiles:

1. Entidades HTML (&, <, >, "): Algunas librerías devuelven el texto plano con entidades sin escapar (donde & cuenta como 5 caracteres), mientras que otras las decodifican a &, <, >, " (donde & es 1 carácter). Para lograr consistencia entre lenguajes, todos los parsers deben operar sobre texto decodificado.

2. Etiquetas <span> de resaltadores de sintaxis: Los motores de blogs modernos (como Astro con Shiki o Prism) dividen los bloques de código en docenas de elementos <span class="line"><span class="token keyword">const</span>...</span> anidados. Algunos parsers HTML insertan espacios en blanco adicionales al unir nodos de texto <span> adyacentes durante la extracción de all_text. Si un analizador añade un espacio después de cada palabra clave resaltada, ¡el conteo de caracteres de código aumenta de forma no natural!

Acto IV: El misterio de Unicode – Grafemas frente a Puntos de Código y Bytes

El descubrimiento más fascinante ocurrió al auditar el artículo #13 (tRPC – super fast development cycle…).

Los resultados de conteo de caracteres de texto para este artículo fueron:

• Rust: 10,424 caracteres
• Python: 10,424 caracteres
• Perl 5: 10,424 caracteres
• Raku: 10,423 caracteres (¡exactamente 1 carácter menos!)

¿Por qué Raku reportaba 1 carácter menos? Escaneé el texto de la publicación carácter por carácter en busca de símbolos fuera de la tabla ASCII. El causante estaba en la frase:

“I learned tRPC today and fall in love ❤️ instantly…”

Analicemos el emoji del corazón rojo ❤️. En Unicode, este símbolo consta de dos Puntos de Código (Code Points):

1. U+2764 (HEAVY BLACK HEART ❤)
2. U+FE0F (Modificador invisible VARIATION SELECTOR-16, que indica al renderizador mostrar un emoji en color).

¿Cómo cuentan caracteres los lenguajes de programación?

• Python (len("❤️")): Cuenta Puntos de Código Unicode $\rightarrow$ 2 caracteres.
• Rust (str.chars().count()): Cuenta Puntos de Código Unicode $\rightarrow$ 2 caracteres.
• Perl 5 (length("❤️")): Cuenta Puntos de Código Unicode $\rightarrow$ 2 caracteres.
• Raku ("❤️".chars): Larry Wall diseñó Raku para operar de forma nativa en NFG (Normalized Form Grapheme). Raku cuenta lo que el usuario ve visualmente en pantalla como un solo glifo $\rightarrow$ ¡1 grafema!

Para alinear Raku con Python, Rust y Perl 5 (contando Puntos de Código), simplemente sustituimos .chars por .codes:

# .codes cuenta Puntos de Código Unicode en lugar de grafemas NFG
printf("| %8d | %8d | %-60s \n", $text.codes, $code.codes, $title);

Con este cambio, Raku logró una coincidencia del 100% byte por byte con los demás lenguajes.

Acto V: Tabla de resultados para los 68 artículos

Con una lógica de conteo unificada y una gestión adecuada del anidamiento en el DOM, generé las estadísticas completas para los 68 artículos publicados en el blog.

Estadísticas resumidas:

• Total de artículos analizados: 68
• Total de caracteres de texto: 504,233
• Total de caracteres de código fuente: 430,084
• Volumen total del blog: 934,317 caracteres
• Proporción global de código: 46.03%

Tabla de mediciones:

Gráficos de evolución de texto y código

Los siguientes gráficos ilustran los cambios en el volumen de los artículos y el porcentaje de proporción de código a lo largo del tiempo:

Acto VI: Enfrentamiento en 4 lenguajes de programación

Desarrollé implementaciones equivalentes del algoritmo de conteo de caracteres en 4 lenguajes:

1. Python (httpx + selectolax)

#!/usr/bin/env python3
import httpx
from selectolax.parser import HTMLParser

BASE_URL = "https://gustawdaniel.com"
res = httpx.get(BASE_URL)
parser = HTMLParser(res.text)

for a in parser.css("h3 > a"):
    path = a.attributes.get("href", "")
    url = path if path.startswith("http") else f"{BASE_URL}{path}"
    post_parser = HTMLParser(httpx.get(url).text)

    code_str = "".join(pre.text(deep=True) for pre in post_parser.css("section pre"))
    for pre in post_parser.css("section pre"):
        pre.decompose()
    text_str = "".join(sec.text(deep=True) for sec in post_parser.css("section"))

    print(f"| {len(text_str):8d} | {len(code_str):8d} | {a.text().strip():<60} |")

2. Rust (ureq + scraper)

use ureq;
use scraper::{Html, Selector};

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let body = ureq::get("https://gustawdaniel.com").call()?.into_string()?;
    let fragment = Html::parse_fragment(&body);

    for element in fragment.select(&Selector::parse("h3 > a")?) {
        let path = element.value().attr("href").unwrap_or("");
        let post_body = ureq::get(path).call()?.into_string()?;
        let post_fragment = Html::parse_fragment(&post_body);

        let mut code = String::new();
        let mut text = String::new();

        for section in post_fragment.select(&Selector::parse("section")?) {
            for node in section.descendants() {
                if let Some(t) = node.value().as_text() {
                    if node.parents().any(|p| p.value().as_element().map_or(false, |e| e.name() == "pre")) {
                        code.push_str(t);
                    } else {
                        text.push_str(t);
                    }
                }
            }
        }
        println!("| {:8} | {:8} | {:<60} |", text.chars().count(), code.chars().count(), element.text().collect::<String>());
    }
    Ok(())
}

3. Perl 5 (Mojo::UserAgent + Mojo::DOM)

#!/usr/bin/env perl
use warnings;
use strict;
use Mojo::DOM;
use Mojo::UserAgent;

my $ua   = Mojo::UserAgent->new;
my $main = $ua->get('https://gustawdaniel.com')->res->dom;

sub collect_text {
    my ($node) = @_;
    my ($t, $c) = ("", "");
    for my $child ($node->child_nodes->each) {
        if ($child->type eq "text") {
            $t .= $child->content;
        } elsif ($child->type eq "tag") {
            if ($child->tag eq "pre") {
                $c .= $child->all_text;
            } else {
                my ($st, $sc) = collect_text($child);
                $t .= $st; $c .= $sc;
            }
        }
    }
    return ($t, $c);
}

for my $elem ($main->find('h3 a')->each) {
    my $post = $ua->get($elem->attr('href'))->res->dom;
    my ($text, $code) = ("", "");
    for my $sec ($post->find('section')->each) {
        my ($t, $c) = collect_text($sec);
        $text .= $t; $code .= $c;
    }
    printf("| %8d | %8d | %-60s \n", length($text), length($code), $elem->all_text);
}

Auditoría de verificación para los 68 artículos:

Todos los scripts produjeron conteos idénticos hasta el último carácter.

Acto VII: Benchmark de rendimiento y reutilización de conexiones HTTP

Con 4 scripts funcionales y 100% consistentes, medí el rendimiento de ejecución en todos los programas (tiempo real de reloj, tiempo de CPU y consumo máximo de memoria RAM Max RSS).

Resultado inicial inesperado

En la ejecución inicial del benchmark, Perl 5 con Mojo::UserAgent tardó 11.39 s, mientras que Rust estándar tardó 5.21 s y Python 5.74 s.

Sin embargo, resultaba desconcertante por qué Python y Rust estándar eran solo ~2 veces más rápidos que Perl, dado que la CPU de Rust dedicó solo 0.37 s al análisis de código.

El cuello de botella residía en la capa de red y la persistencia HTTP Keep-Alive:

1. Mojo::UserAgent en Perl reutiliza conexiones TCP/TLS persistentes.
2. La versión estándar de Rust (rust/src/main.rs) invocaba la función estática ureq::get(&url) dentro de un bucle. Al no disponer de un agente compartido que gestionara un pool de conexiones, cada una de las 68 peticiones abría una nueva conexión TCP y un nuevo saludo TLS.
3. En Python (count_text_and_code.py), se llamaba a httpx.get(url) dentro del bucle, creando un cliente efímero por cada petición. Si hubiéramos utilizado with httpx.Client() as client:, Python también habría mantenido un pool de conexiones Keep-Alive.

Optimización en Rust: rust/src/bin/connection_pool.rs

Instanciamos un agente explícito ureq::Agent::new_with_defaults() que mantiene un pool de sockets abiertos y los reutiliza en peticiones sucesivas:

// rust/src/bin/connection_pool.rs - agente explícito con pool de conexiones
let agent = ureq::Agent::new_with_defaults();

let body: String = agent.get(BASE_URL).call()?.into_string()?;

for element in fragment.select(&selector) {
    // Reutilización de conexiones TLS existentes mediante la misma instancia de agente:
    let post_body: String = agent.get(&url).call()?.into_string()?;
}

Métricas finales de rendimiento

La siguiente tabla presenta las mediciones precisas de tiempo y consumo de RAM registradas en todas las implementaciones:

Gráficos comparativos de rendimiento

Tiempo Real de Ejecución de Reloj (Wall-Clock Real Time)

Tiempo de Procesador de CPU

Consumo Máximo de Memoria RAM

Resumen

Lo que comenzó como un simple cálculo de métricas se convirtió en un valioso estudio de ingeniería de software:

1. Particularidades de las librerías: Incluso paquetes populares en CPAN pueden contener errores en expresiones regulares que truncan atributos en comillas simples.
2. Jerarquía del DOM: Rastrea de forma recursiva el contexto del nodo (como <pre>) para evitar clasificar etiquetas de código anidadas como texto del cuerpo.
3. Especificación Unicode: Antes de comparar longitudes de cadenas entre lenguajes, verifica si estás midiendo grafemas (NFG), Puntos de Código o bytes UTF-8.
4. Rendimiento y Memoria: Rust con Connection Pool logra un tiempo de ejecución de 3.34 s requiriendo solo 15 MB de RAM (5.7 veces menos que Python y 26 veces menos que Raku).
5. Optimización de E/S de red: Reutilizar sesiones HTTP Keep-Alive tiene un impacto drásticamente mayor en el tiempo total de ejecución para tareas orientadas a red que la elección del lenguaje de programación o la velocidad pura del analizador HTML.