Lo snapshot di copertura del 30 luglio registra 1.017 funzioni interne su 2.143, 539 / 654 funzioni core e 2.649 test Zend superati. La milestone applicativa è ancora più grande: le suite core WordPress complete girano ora a parità effettiva con l'oracolo.
Baseline WordPress complete
| Suite core single-site | 30.472 test · 1 divergenza dichiarata per nome |
| Suite core multisite | 31.278 test · 1 divergenza dichiarata per nome |
| Database e server | MySQL reale tramite MySQLi nativa · phpr -S |
| Workload HTTP | Frontend, login, REST, wp-admin e pretty permalink a parità byte |
L'unica differenza per nome è deliberata e documentata: stream_get_wrappers() elenca soltanto i wrapper davvero implementati da phpr. Restituire un elenco più ampio e plausibile violerebbe la regola «corretto oppure assente».
Il workload ha guidato anche un ampio lavoro sulle estensioni: media byte-identici tramite libgd di sistema più EXIF e fileinfo native, XSLT su libxslt con callback PHP, ext/tidy completa su libtidy, XML SAX, codec mbstring più ampi, hashing password Argon2 e un sottoinsieme intl.
Guarda WordPress in esecuzione su phpr
Questa registrazione mostra il progetto al lavoro con un'installazione WordPress reale e completa visivamente i risultati misurati sui test e sulle risposte HTTP descritti sopra.
Video ospitato da Loom. Apri la registrazione su Loom ↗
Copertura misurata di linguaggio ed estensioni
| Corpus Zend | 2.649 pass · 65,1% dei test eseguibili |
| Libreria standard core | 539 / 654 · 82% |
| Tutte le funzioni interne | 1.017 / 2.143 · 47% |
| Aree funzione completamente chiuse | 11, incluse xml, fileinfo, tidy, session e PDO core |
Prestazioni e memoria diventano ingegneria misurata
Il lavoro di ottimizzazione non si riassume in un solo benchmark. La banda di riferimento corrente colloca la CPU full-suite a 2,06–2,11× dell'oracolo, da circa 4,1×; il gruppo media WordPress è a 2,58×, con footprint corrente attorno a ~3,0–3,1×.
Il percorso comprende un cycle collector stile Zend, mark di cammino dentro i nodi, correzione della proprietà dei descrittori, stringhe growable, indice hash degli array senza chiavi duplicate, stub-elision lato compilazione e census esatti della memoria. Soprattutto per un server residente, WP-72 ha ridotto il residuo misurato da circa 2,11 KiB per richiesta a 0,0010 KiB/richiesta, con 0,000 oggetti trattenuti per richiesta nella tripla definitoria.
La fase worker-attore Axum
Con il teardown misurato piatto, il progetto ha aperto la rotta Axum. La VM contiene stato basato su Rc ed è !Send; l'architettura accettata fissa quindi la proprietà a worker su thread OS dedicati e distribuisce le richieste tramite message passing. La coda corrente è ancora non limitata; backpressure e coda bounded restano gate di rilascio.
Nello snapshot corrente, il percorso worker esegue esplicitamente request_start → vm.run → request_shutdown → request_end. Ogni worker dedicato mantiene ora un solo RetainSet per tutta la propria vita e due richieste sequenziali sul worker hanno superato il gate di parità byte. La richiesta riceve ancora un modulo ricompilato e una VM nuova: persiste quindi lo stato del worker, non ancora la stessa istanza della VM.
Il prossimo confine da provare
I gate successivi sono volutamente stretti: due richieste sulla stessa VM devono coincidere con un run fresco; un'amplificazione K=10 deve restare piatta; i percorsi fresh e reuse richiedono una coppia con l'oracolo; e va verificato l'ordine di shutdown per handler, buffer, distruttori, sessioni e fallimenti. Solo dopo sarà possibile misurare onestamente throughput, code ed economia dei worker longevi.
Laravel resta il prossimo grande target di validazione framework dopo il lavoro corrente sul confine prestazioni/server, mentre gap delle estensioni e robustezza proseguono in parallelo.