Newsgroup: it.comp.java
Titolo: JSON e occupazione di memoria

Per spiegare il mio problema, probabilmente conviene partire con 
l'antefatto. 
 
A causa del fatto che sembra non esistere un programma di backup che faccia 
le cose come dico io, mi sono deciso a scrivermelo per fatti miei. Per 
scriverlo ho deciso di usare Java sia per il fatto che mi serve un 
applicativo multipiattaforma, sia perche`, oltre alla copia diretta di un 
file, mi permette di implementare interfacce dirette ai sistemi che mi 
interessano (e.g. Svn, database ed altro). Per l'implementazione, ho seguito 
un modello client/server in quanto non tutti i sistemi operativi su cui 
andro` ad operare mi permettono di eseguire comandi remoti (e.g. Windows). 
Operativamente parlando, seguo questo flusso:
 
1) Il server richiede la lista dei file prensenti in un determinato percorso
   al client per mezzo di un json opportunamente formattato;
2) Il client scansiona il percorso e ritorna un json contenente tutti i file
   presenti nel percorso richiesto;
3) Il server analizza il json e richiede al client di trasferire solo i file
   modificati.
 
Il problema e` che il client, per generare il json, arriva ad occupare in 
ram anche piu` di 600Mb, cosa inaccettabile soprattutto per il fatto che 
tale memoria non viene piu` rilasciata, rendendo di fatto l'applicazione 
inutilizzabile in ambito produttivo (non posso allocare cosi` tanta ram per 
un'attivita` "secondaria"). Come posso risolvere? Facendo un po' di prove 
(e.g. spezzando il json) sono riuscito a far scendere l'occupazione di 
memoria a circa 100Mb, ma rimane comunque alto per i miei scopi. Per chi ha 
voglia di vedere un po' di codice, il progetto e` hostato su 
https://github.com/henryx/backupsync
 mentre il codice problematico e` in 
questa classe 
https://github.com/henryx/backupsync/blob/master/src/org/application/backupsync/client/context/commands/CommandFile.java
 
 
Enrico

 
https://github.com/henryx/backupsync/blob/master/src/org/application/backupsync/client/context/commands/CommandFile.java
 
 
Non e' probabilmente la causa del memory leak che riscontri ma nel costruttore:
 
this.json = new JSONObject();
this.json = this.list(aDirectory, acl);
 
la prima riga ( "this.json = new JSONObject();" ) e' sicuramente del tutto inutile visto
che la riga successiva sovrascrivi this.json.
 
Riguardo al memory leak se creassi un mini-programma autocontenuto utilizzando org.json.JSONObject
(un solo file con la classe CommandFile e una main che lo utilizza, senza nessun utilizzo della rete)
magari si isolerebbe meglio il problema e lo potrei provare anch'io piu' semplicemente.
 
Ciao.
 
 

 ram anche piu` di 600Mb
 
Forse dovresti usare i path relativi, in una struttura opportuna per 
poter ricalcolare quelli assoluti, perche' ad occhio il grosso del 
consumo sta là. Anche se 600 mega per stringhe di path? Mi pare assurdo...
 
Forse dovresti aggiugnere un test case in modo che tutti possano verificare.

 cosi` tanta ram per un'attivita` "secondaria"). Come posso risolvere?
 
ti suggerirei di dare un occhiata a un parser/generatore json in grado di 
fornire delle streming api, tipo jackson:
http://wiki.fasterxml.com/JacksonInFiveMinutes#Streaming_API_Example
 
 

 Anche se 600 mega per stringhe di path? Mi pare assurdo...
 
Il problema e` duplice:
 
 - 600Mb li totalizzo su path belli popolati. Ad esempio, il ramo git
   ufficiale del kernel linux al commit ...400ea64059e5 e` formato da 38165
   file e 2347 directory. Questo significa che il json contiene 40512
   elementi.
 - Il json non contiene solo il path, ma anche informazioni relative al tipo
   di oggetto (file o directory), dimensione (file), hash (file), date di
  modifica, permessi ed eventuali ACL impostate.
 
Ad esempio, questo e` un pezzo del json di ritorno:
 
{"/home/enrico/linux/README":["{\"acl\":[{\"users\":[{}],\"groups\":[{}]}],
\"hash\":[\"fd587f0bee9166e00254a53cc711af44\"],\"attrs\":
[{\"posix:symlink\":[false],\"posix:group\":[\"enrico\"],\"mtime\":
[1323608048000],\"posix:permission\":[\"rw-r--r--\"],\"posix:owner\":
[\"enrico\"],\"ctime\":[1323608048000],\"size\":[17459]}],\"type\":
[\"file\"]}"]}
 
Enrico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQIcBAEBAgAGBQJPLvUTAAoJEIgbS5QK93sQ93UP/0F7zTqAX6ca//W6wKMHIYuV
cw0IvT7o+m0F55IZNAc3Lpa/jnYuFJNt5gC2crCQ/0k91J2PDfwRYRdF3W3CdLTg
HsBCit8nHFosvoKGUmjA13+xnu9XYnyUwdRU74ogjB1DXimH8BGED0aOLkGcXThN
wN8YvjQFRoNoDAJfM734uia9X8SHdKU5xddnfV2OuB2qZUEwhhySxh0e/a8mKHX/
CGSe2E+go7yBb2s2Nv3LuYQVxYrwOYa2WqyeIxP0LDYzqQWNWKX074jjA00dbkF0
XzD8CIItsB+vp1fD/Qij5ewMYpPxMmYWBrco1qOP287DNJjoJ//qCFlJ6Ue0rWck
Owp9SfL1SyauLxFn2yTQYzv56yM6yvjYznaP0LAgkcHCL0IdBjAwCJLmFPIKU07J
DVVAop1TwV2h+iB4pLoE4ipdUCqurhtRfB1g74weSCWWEaxWTDDFfxb/BLkO7mpv
e8s5ZX/aJklNFakGVz+wjSRookZS+KGYp7j3Uvm5w+QhQjFu8K4PyBiSFYcDUhWW
dK8mEeSq+4UtWp3YGm/Nf7gaBfEguapY0rJTiJI+DQ4HqzQqAZDDI1eOFN9bIcHy
ASN4xwAEsVJ7N+yCYsPVwjTdT9x75trv2ADFr/O76x4lzMpQ0zWlTrfa3vnwqGpv
gUlk7/sqYf0Hg0B8uDKs
=9ZAa
-----END PGP SIGNATURE-----
 

 fornire delle streming api, tipo jackson
 
Il problema e` che non vorrei dovermi trovare a riscrivere praticamente 
tutto il codice, visto che l'uso che faccio della libreria json e` altamente 
invasivo
 
Enrico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQIcBAEBAgAGBQJPLvdFAAoJEIgbS5QK93sQZfsP/0MKVGAdZBmh2xP9QzzUm22R
Ej7cC47SLzXIeEU95XODfey1w7P8gFLSL2WROhleXo7LC3A7QkkeMGCBgL8n14I9
k4jRGpfTj8PPuruCW+r/PpsHa/nOnVVGUTOr4Yg48UZYel7c7ARIXtoP/0Os1Fvx
oAeenBHGGgrqYzKL7kYaUQJzg4oytqi5Aq0GJy+psLb80puH5hNh3zowfqatPIMu
eE9BHLez/9vNreiskK8u5spK0UZT854wG6ZRkECJQe5wGupOTGN0EMbwC+G8XtB1
rYhSobB/lM8mvZh2Uzc7T1es63+VS3gFYGN54+4LauGzwnB10Q/YcMo+2hRzLP/V
JXDJy40uirM2l/soHC4w8kME4Eg9gc1TOAlWr8fGX8kv+YnymlOnTVC/+Qd/DXTu
E4ObiMXgPxVSnH7QUpMGrSBi+PfvKOTfODpiB3a+ow8YuOPbwJnrLkVU3t9huAla
M/Kn5kf9Pb2xQIhVWMxIfQL8SAlOHScl03/6Mp+SrIb06AkZ+HSH2kjqXdr/MlL9
QLCV6PfHJqSAS4Nw6THEqBFgE79+KypsLycCzHbGgFMBWnoX+V5pGFKClthELnfX
2yLjt8HH3PNt/GSIj2AXOWCgX9s66dwgEcFmaS19Vrvi5504MYbuF9Yw6SrSW1JT
unUZ7xRIQB67kePKxhkh
=yLqZ
-----END PGP SIGNATURE-----
 

 semplicemente.
 
Il problema posso gia` dirti che e` dovuto la classe CommandFile in quanto 
ho gia` provato ad isolare il problema ed ho riscontrato che e` li la rogna. 
Per quanto riguarda l'utilizzare l'applicativo, basta che lanci la classe 
og.application.backupsync.Main con lo switch -p <porta> e, su di un prompt 
dei comandi, esegui un telnet localhost <porta> ed incolli una stringa json 
come questa: {"context": "file", "command": {"name": "list", "directory": 
["<directory>"], "acl": true}}
 
Enrico
P.S. una doverosa precisazione: per ora mi sono limitato a sviluppare ed a 
testare sotto linux, ancora non ho le idee ben chiare se tutto questo 
funziona sotto windows
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQIcBAEBAgAGBQJPLv5cAAoJEIgbS5QK93sQU3oP/A3Cw1zoKmwnCnsheVnuyBUJ
8o+5BwGPiLKzABg194CT/xWjwip4PL//ZtCO3JC7/3FPKKV55gYMJHEtiQjh8V7l
s/qdvOwr3i8UwNpk6TxUUECwBSEYfgBbJx/Ye0aQWox1WHo8VrSgbE5fL+4HOsxD
OKSfs4JzpoS0kgY4kRh9Ta8VcqoTbknGfjB8dFOlefAv2kZom31nq9yAXER+o++Z
G5xIloy7Q6GQJCE2j/ki+9jEA70IZxNNek63O2LPUr5OQTnqjuUFB8tcCcPn8LvI
B505woAmNcUEPAZalwh4TxJ+jkxkrwiId4TZija2oeOE/sn2c0FuTYa5wUYJGpnT
5aZSah5hYD6arXFd+2xiIJ40BXTx8u6aG1h06ceXdh6akzRZfVCtJHnUd61JJKZx
8fe0jGX5rQxBNk3VDs/wZqRwjEnrNP9TGt7RlWg+uId5ZnnrsDizyxpfGKq8+fjo
BD1fvusw0XCXHRUfjQwSN5sUkAK+NRTf/fHiVFu+pvMB+drQoOuQNtR0UcfsEbk3
kh2AHbPlRJrSHAsTxigosgaS37++xQI0nq5zF971+1dVVvJInVDNLWEMTJT8Eq7U
etIf9dFxrwqHNwJY5Efw0C6rJHIvL1HmdbueDKj2N7N++ptnqLPP7WRWTxE3NWVt
GSB+D5FaNG78GvVt3su4
=ybCd
-----END PGP SIGNATURE-----
 

 a diritto).
 
scusa non è morphing è una identità del piffero che uso per mettere
dei post su it.test e rileggerli con un mio programma...

   modifica, permessi ed eventuali ACL impostate.
 
Però in memoria ti ritrovi con 15MB occupati per elemento.
 
Per quanto l'oggetto JSON tenga altra roba in memoria la parte che scala 
molto è il percorso, il resto più o meno rimarrà grosso modo lo stesso.
Il tuo esempio è di 356 caratteri, anche volendo stare larghi e 
ipotizzando 1 KB di risposta JSON ad oggetto avresti circa 40 MB di dati 
utili.
È plausibile una tale differenza di dimensione tra il payload e un 
oggetto allocato nella macchina Java? (non so se l'oggetto sia una 
stringa o più articolato)

 ho gia` provato ad isolare il problema ed ho riscontrato che e` li la rogna.
 
Io ho dato una compilata con una main cosi' fatta:
 
     public static void main(String[] args) {
         try {
             while (true) {
                 System.out.println("memory free before: " + 
Runtime.getRuntime().freeMemory());
                 CommandFile cf = new CommandFile("/opt", false);
                 JSONObject json = cf.get();
                 json = null;
                 cf = null;
                 System.gc(); System.gc(); System.gc(); System.gc();
                 System.out.println("memory free after: " + 
Runtime.getRuntime().freeMemory());
             }
         } catch (Exception e) {
             e.printStackTrace();
         }
     }
 
La memoria libera oscilla sempre intorno allo stesso valore,
da questo test non mi e' sembrato esserci un memory leak in quelle classi.
 
In /opt avevo un migliaio di file e se redirigevo il json.toString() su 
un file ne ottenevo uno da qualche mega.
 
Ciao.

 da questo test non mi e' sembrato esserci un memory leak in quelle classi.
 
Ahhh, forse trovato, invece usando:
 
CommandFile cf = new CommandFile("/opt", true);  // true invece di false
 
la memoria libera mi diminuisce costantemente (~100k a iterazione).

 la memoria libera mi diminuisce costantemente (~100k a iterazione).
 
Comunque dopo qualche minuto si stabilizza... forse non e' neanche qui 
il problema. Notte.

 in ram anche piu` di 600Mb, cosa inaccettabile soprattutto per il fatto
 
hai profilato il programma per vedere cosa esattamente occupa quella ram?
una volta capito cos'e' si puo' ragionare sulla causa.
 
ho usato due volte il profiler in casi simili ed e' stato illuminante.

 da questo test non mi e' sembrato esserci un memory leak in quelle classi.
 
attenzione perché richiamando esplicitamente il gc ti metti nelle
condizioni di "barare" nel test rispetto all'ambiente reale. se hai un
processo che ciclicamente alloca oggetti a vita breve è normale che tu
abbia bisogno di un adeguato spazio heap "eden" per contenerli, perché
non puoi pretendere che il garbage collector spazzi ogni volta che si
dealloca un oggetto (fra l'altro la chiamata esplicita non è detto che
risponda, il gc non è un elemento che si comanda programmaticamente).
se non vuoi assistere ad un growing del consumo di memoria (che *non*
è un memory leak) l'unico sistema da codice è evitare che vengano
allocati e dereferenziati tutti quegli oggetti. se questo non è
possibile allora occorre fare un tuning della memoria e del gc
opportuno accettando il compromesso che, per gestire quella
situazione, ti serve un buffer adeguato per la young generation.
 
una lettura che assolutamente non può mancare:
http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
 
 
 

 ho usato due volte il profiler in casi simili ed e' stato illuminante.
 
Quali strumenti suggerite per il profiling di un programma scritto in 
Java? Lo chiedo da Java-agnostico.

 Java? Lo chiedo da Java-agnostico.
 
io uso il profiler integrato in netbeans

 hai profilato il programma per vedere cosa esattamente occupa quella ram
 
Si, l'occupazione e` dovuta soprattutto ad una allocazione spropositata di 
oggetti di tipo byte[], dovuta principalmente all'allocazione di oggetti di 
tipo org.json.JSONArray() . La cosa interessante mostrata dal profiler e` la 
dimensione dell'heap rispetto a quella usata una volta terminate le 
operazioni di scansione della directory
 
Enrico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQIcBAEBAgAGBQJPMGAgAAoJEIgbS5QK93sQhuUQAIbKoS5ZkyqNj3gsCTjH2az0
r4fN0HrDxzx8PWD77hY8Ol1westWpzoyIAI5slGcXAqUQzCdjif9t5WuWUpTiscq
Mz/j/Lj4FQkkBjZqEqN1D3uhq514rt3MM38OrLflBJUttOjiCNi2gPRJPp8L1VMR
Mnmo5KF8rXRL9aAFlWNEDR/b60oxaniMM3safp1D9vL0VfIBahHEDenFdnDImO5q
3N5o0pwXi/W9N3P9O2YHBuTbNQY5HX/yyoO7ZVEbcD+Th/mW1XbRXRVhHEm386Xq
/sQwlNnzpZ9wwdMKmEDlDxTSjEj896NOzty6fGf58ccvh+b8Hd9oXj338hamFnVg
p9XA70wJYGidLDARDadSOtEwpZd3KdzZz6pFXPx7f42o5XNXI4EW1ErKaGQ0bvhW
pXnnXU406gO+IbpIOITtcsh2BImmPdw9GzOThiEb0HgSdhGc1WgMsvyO50wtKx9M
oKNh/gQxWZwVvSI9ZqXawV++rFEID9Q0I+BoKHFhRLAhhUeBtAgP7XCFwExEYbYV
fwuhF1Wlb+oWlGfyYLmyybsvJLfvRUIiOULQhNKQQH0yV5WNmexOgahdEbhysAm/
djKlVjtRyppk09KBsNFtz4f0tr6jdvlxAIytziWoT2qTiFmdfRlx12GHE9TPhHLd
7ZtsbKAYRug6pm6RVi0n
=q6tH
-----END PGP SIGNATURE-----
 

 molto è il percorso, il resto più o meno rimarrà grosso modo lo stesso.
 
Non e` detto. Ad esempio la parte delle ACL puo` diventare abbastanza grossa 
in quanto va a salvare dei JSONArray contententi gli utenti ed i gruppi 
impostati sul file
 
Enrico
P.S. ho notato or ora che l'estrazione delle ACL non funziona se il file ha 
uno spazio nel nome, dovro` indagare sulla cosa...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQIcBAEBAgAGBQJPMGbeAAoJEIgbS5QK93sQeIwQAIuogfBcYEE3V1/0NMTAAFw+
DqeMVeP3hSIiHxYqvfYlNOreojQM2MY1A0BU4BJbBl4a0ual26fWyd3VHay8AKIz
UK1DZqwRyozhdNDS6TljPxtHtlgIzeBYLAE/SSHMbRq6j45i0EJbOUebcQeYMQGF
I6wl0+z1FhKyby3TRuQW3R59gP1U5oZvPxLJfFuocTEIXOzZy7mBpw7NxHIUKh34
C3j8Oj/nmCj6Acb1s7CCo/zbKgIpPEqP0Cwu1N+5/5ZB7hQ8EXK9MiOa8Y5f+H7g
jb4imiP0j9eNfDEPZ6sIvXa+Vh0qs3uuQblInMvhNcS84kwm6x5nYb6QBsCGG/ck
CVkafgiew6PYK7sbVfMZ1j0V9FohFHYMG5WtL0sxcUQK55fvSvhYLVL3AHsP64aA
TYDfXijGqsegmHH7fZcq5qL/g+BJtFf2krgIETSyrxF7w1HCUbjijzylc/fAtTHB
GNu5zE4GdDgr11Dd/sSgFXsuPnn0Eo9ykVtZo7S/1j2KA8U4RGL2jA+hrP3eZnAx
qpcOs6lrgz5M9wAzS3lje9vz/l9DV3r/kVfu+LVlFCxXnQ9LNIcR/tJNhs4gAReO
nS4cQS+Xo2MkJGKmqHjijfhZRAWFBB3Pr3fveNKWvKbyWq0Ji91ZFU23Mgzuum9+
h7dC7X5Qm3dWiLb7hTP1
=7vJf
-----END PGP SIGNATURE-----
 

 il problema. Notte.
 
Eh, non so piu` nemmeno io dove sbattere la testa, a 'sto punto sto pensando 
di riscrivere tutto e di usare una libreria JSON che implementi lo streaming 
diretto del json risultante
 
Enrico
P.S. giusto per, in Python 3 un problema identico l'ho risolto implementando 
un generatore che sputa un json per ogni elemento processato (qua anche 
utilizzando un json per elemento ho picchi di memoria abbastanza alti)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQIcBAEBAgAGBQJPMGgXAAoJEIgbS5QK93sQ4KcP/1efBQhgqZPjlQwnYVp3vk64
lsU9Bm3xUfZ7t5wAdJKpm0gVuRJFqj2ANymGA3yw9SXuNrGADJVxrSXmO6QqiQlX
Jahoh1G4TyvUiMFoi2b5eDp9u3HtDiSqJOQrQmjocGoLVojjrmXVeeZxH1eX4Dei
YfFV8HBnWrNAWDV/wjsfgj5i4ljq0exFmoOnVGoIYxWiy8LVdZKq7y8Gee9ML8v6
xqb8FvBpqPckEwAcGC20l4F9IUnMILS8zUr9s9qo6OAgIVd2I67qsukr1FOwdjZf
bENrv2T5fcHUTQURgzYLzKC7fAYYU1aTqrIvkWqUWw6M+lk7/XcGkRHo6r7CvbAS
WdtXwhf8yAMwgXDwQKcnvb5Vx0n9fxb9/BqZfUO09nvvX2UBcXgKLrHtaodXDD81
rpz52KBDKIXbtMFV06ROx/c9i6PwqSsbDRNZzu0g483dsv2BfUMfK48GjPh0sCK2
6e5SjlRwq1JHBHAQwjcuSDa0f2KHvY1PQlKmVoB1OXUOeUChDgZqhDfqIU3eAB5K
SUqPdM3zKp7jzWgbdAcO97KURNq3VKrza+l31h41YWXjWzMjv9ZythCi4GZnUuwm
EcHI+S1KdjKN7bJ0QSUFnLRC1L8YunX5BTgkEn1n507IAbTTZxKgJj+0Dy1DzOqR
pRJOlXTzV6KGpc/teiYv
=uWHC
-----END PGP SIGNATURE-----
 

 terminate le operazioni di scansione della directory
 
un problema simile l'ho avuto usando jdom o un simile per parsare un 
grosso XML....l'unica soluzione trovata e' stata frammentare l'xml in piu' 
file

 Eh, non so piu` nemmeno io dove sbattere la testa
 
Hai provato per caso il tuo scenario mettendo acl a False nel 
costruttore di CommandFile (quello che causa o meno l'esecuzione di 
getfacl) ?
 
L'utilizzo della memoria e' estremamente inferiore senza getfacl.
 
Ciao.

 getfacl) ?
 
Posto che non posso fare a meno di richiamare getfacl (mi servono le ACL 
impostate sul file e Java 7 permette solo la lettura delle ACL NFSv4), il 
problema non e` nemmeno lui, e` proprio il JSON generato che manda alle 
stelle l'uso della memoria. A questo punto dovro` farmi forza ed usare 
un'altra libreria per generare il JSON (e` ovvio che vi terro` informati :) 
)
 
Enrico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQIcBAEBAgAGBQJPMXCSAAoJEIgbS5QK93sQJNoP/3rG5BABzMfbQ2Rjf7y1+871
GMUK5xs/TusfWonxJqcDZ85uZF6sVWKbEu/ggmtXAk4cvYaBO3JWYcCIgz3HeX7B
gjB8M7dPG9IMxrE/X26uXFUToqQ9WHGz1MKjxEaBhk0XxsurFbhsO44TaEyMOfW7
K79fPZXRXnx7EbJVSQ1zJQHuy3B71JsOa7FVV6njZJS6a9p4YMh+cOuyFK0V3BM9
jhAew9Wibhx6rNSdVdfm2VomwNOMuDqHte1dookHEWtMnMLI1TqRYOvlT3dj7hsL
xfgtvTCLNoWPYh4X8cRxwciD3AXSBnNWQZx/hTWmx5z0AyBFRxUq9KNMUiFbP3zx
nlCD0zn5k7HlD1Jilj4birWHGRd4Snb0Kzw/5v1ZZFp/bund+KXjqoRPMY18ccL/
D5PoMZb0s3NtFpfjfTRMx+25Alrt/ImKrUUAim0SM54RaJeEIe4+S0Bpv67KKpHN
FxDZiET3aQ8c9n+5MD/T/43mM6ODOsCWikVgEqNI/yLCm2ShDexiQ/W3+rXsW7w7
70FYjhwO6si359J2Q3sGioZVdAawIAywfEc3GgZFphLYPLzWZnN3zNrUKPs5DHre
ap6y5znAmVrlxHMKp5sKTtUKgXAUS/uPzTBtDdEaMIFdglOTSvKA/1eI1pe982Ed
sU86Eypw9ln34yJV7ybF
=AJsQ
-----END PGP SIGNATURE-----
 

 Come posso risolvere?
 
Ok, in teoria avrei risolto nel modo piu` sanguinoso: ho buttato le classi 
base di JSON ed ho usato FlexJSON. L'occupazione di memoria, almeno su di un 
albero grosso come quello del kernel Linux, non supera i 150Mb (sempre 
altina, ma comunque molto minore di quella precedente). A questo punto non 
posso dire di essere completamente soddisfatto, ma almeno ho una base per 
poter dire "vado avanti" :)
 
Enrico