web analytics
canonical snap new compression algorithm

Canonical: Snap più veloci grazie ai nuovi algoritmi di compressione

Tramite questo post pubblicato sul sito ufficiale, Canonical ha svelato alcune novità che consentiranno di velocizzare l’esperienza d’uso degli Snap. Per ottenere questo risultato il sistema di distribuzione delle applicazioni subirà un cambio dell’algoritmo di compressione.

Canonical: nuovo algoritmo di compressione degli Snap, si passa da XZ a LZO

Chi utilizza quotidianamente Ubuntu o una sua derivata, sa bene che sussiste un vistoso problema di performance. Il tempo necessario per avviare un’applicazione installata come Snap risulta spesso superiore rispetto a quello necessario per l’avvio della stessa applicazione installata tramite i metodi tradizionali. Problema che si riscontra in particolare al primo avvio dell’applicazione, prima che i dati della stessa vengano memorizzati nella cache.

snapcraft

Canonical, tuttavia, pare abbia trovato una prima soluzione per cercare di migliorare le performance e, al contempo, non diminuire la sicurezza generale che caratterizza gli snap. La casa madre di Ubuntu, infatti, pare sia riuscita ad ottenere un miglioramento di 2/3 volte nei tempi di avvio delle applicazioni, cambiando l’algoritmo di compressione.

ubuntu canonical snap store

Per impostazione predefinita, gli snap vengono impacchettati come squashfs compressi, utilizzando l’algoritmo XZ. Ciò si traduce in un alto livello di compressione ma, conseguentemente, aumenta la richiesta di potenza di calcolo per decomprimere ed espandere il filesystem per l’uso. Per migliorare la situazione si è scelto di provare LZO perché offre un elevato livello di compatibilità in tanti scenari. Le conseguenze di questa modifica sono, di fatto, due:

  • Minor livello di compressione, ovvero una maggior dimensione dello snap compresso. A titolo esemplificativo Chromium passa da 150 a 250 MB;
  • Minor potenza richiesta per la decompressione, ovvero minor tempo di attesa necessaria al primo avvio dell’applicazione.

I risultati dei primi test

Canonical nello stesso articolo ha anche pubblicato i test effettuati, utilizzando come applicazione di riferimento proprio Chromium. In particolare dichiara di aver utilizzato una serie di computer portatili commercializzati dal 2015 al 2020. Entrando nel dettaglio, le macchine utilizzate sono:

  • 4-core/8-thread Intel i5, 16GB RAM, 500GB SSD, Intel UHD 620 graphics, con Kubuntu 18.04;
  • 4-core Intel i3, 4GB RAM, 1TB 5,400rpm HDD, Intel HD 440 graphics, con Ubuntu 20.04 LTS;
  • 4-core Intel i3, 4GB RAM, 1TB 5,400rpm HDD, Intel HD 440 graphics, con Fedora 32 Workstation;
  • 4-core/8-thread Intel i7, 64GB RAM, 1TB NVMe, Nvidia GeForce GTX 980M, con Ubuntu 20.10.

L’uso della compressione LZO offre miglioramenti all’avvio a freddo del 40-74% rispetto alla compressione XZ. Sul computer con Kubuntu 18.04, in particolare, lo snap compresso con LZO quasi identico alla versione del browser installata tramite pacchetto .deb. Su Fedora 32 Workstation, invece, l’avvio a freddo dello Snap con compressione LZO è più veloce del pacchetto RPM di un 33%. Si parla di una differenza effettiva di circa 5 secondi.

In tutti i test case lo startup time con LZO è stato inferiore rispetto a quello con XZ. La grande differenza comunque si nota in caso di cold start (ovvero senza dati in cache). Quando i dati dell’app sono in cache la differenza all’apertura è praticamente nulla (decimi di secondo).

snapcraft

Per quanti fossero interessati a profilare il tempo di avvio di una qualsiasi applicazione, Canonical ha anche rilasciato uno script, disponibile su GitHub. Questo consente di confrontare il tempo di avvio di qualsiasi software nativo con gli snap, ed è progettato per funzionare con qualsiasi gestore di pacchetti, quindi può essere utilizzato su qualsiasi distribuzione.

sharing-caring-1Seguiteci sul nostro canale Telegram, sulla nostra pagina Facebook e su Google News. Nel campo qui sotto è possibile commentare e creare spunti di discussione inerenti le tematiche trattate sul blog.

Altre storie
kde plasma bigscreen
Plasma Bigscreen, seconda beta e grossi passi avanti