main_memory = 3000000 % words of inimemory available; also applies to inimf&mp
extra_mem_top = 0 % extra high memory for chars, tokens, etc.
extra_mem_bot = 0 % extra low memory for boxes, glue, breakpoints, etc.Non capisco bene che cosa siano quella “high memory” e “low memory”, se i due valori siano indipendenti, di quanto sia possibile/consigliabile aumentarle. Due valori possibili sono 2 milioni e 4 milioni; ma andrebbe bene metterle entrambe (poniamo) uguali a 10 milioni? A 100 milioni? La prima a zero e la seconda a 100 milioni? La prima a 100 milioni e la seconda a zero? Insomma, avrei bisogno di informazioni così. E se volessi modificare anche la “main_memory”? Potrebbe essere necessario? Ovviamente, tutto questo è terrificante, mi ricorda gli albori dell’informatica, quando si doveva specificare a mano l’occupazione della memoria per ogni applicazione; oggi queste cose le fa automaticamente l’OS; analogamente, dovrebbe pensarci LaTeX, a prendere la memoria che gli serve! Mi hanno detto che Lua lo fa, ma LaTeX no.
Come vedi è scritto di finaco a ciascun tipo di memoria a che cosa serve; la main memori è un po’ di uso generale e le statistiche alla fine del file log parlano essenzialmente di quella, anche perché la maggior parte degli utenti non ha riservato nulla per le memorie extra alta e/o bassa, quindi è difficile riportare statistiche su qualcosa che non c’è.
Le altre due servono per memorizzare le cose che vi sono scritte nei file di commento. Perché una sia memoria alta e una bassa non lo so e non è molto importante, salvo il fatto informatico di riservare quei pezzi di memoria in aree della memoria reale disponibile ad indirizzi alti piuttosto che bassi; Tutte queste aree di memoria sono stivate nella RAM quando sono in uso, quindi i massimi dipendodono da quanta ram si dispone; 100MiB potrebbero essere troppo in una vecchia macchina con 500MiB di RAM, e un ammontare insignificante in na macchina come quella di Tommaso che ha 8Gib di Ram; ma dipende sempre da quanta ram è impegnata dai programmi e dai dati dei processi residenti e di quanto swap di memoria si è disposti a sopportare; più si scambiano dati fra la RAM e il disco, più lenti sono i processi “più” significa una maggiore quanti dati di dati e uno scambi più frequente.
Con i nostri Mac standard con 4GiB di Ram i numeri che hai proposto non dovrebbero dare problemi; ma se sia meglio aumentare la memoria bassa piuttosto che quella alata dipende dal numero e TIPO di dati da memorizzare. Con pgfplots sembrerebbe che le scatole siano l’oggetto più usato e del quale ci sia maggiore necessità di memoria.
Ricorda quanto ho detto sulla risoluzione delle figure vettoriali; esse sono a risoluzione “infinita”, stiracchiando il significato delle parole, ma non ad occupazione di memoria infinita, anzi. Se volevi dire con un numero alto di campioni, e poi questi campioni sono 100 o 200 (o 900 = 30 \times 30) per quelli bidimensionali, si tratta di numerosità forse leggermente superiori alle reali necessità, ma non riguardano la risoluzione, a meno di non voler stiracchiare anche qui il significato delle parole.
Anche se pgfplots fa cose meravigliose, esso deve sempre fare i conti con una macchina che esegue calcoli con i numeri interi e solo con i numeri interi; quindi ogni operazione con i numeri fratti richiede continue acrobazie che in un modo o nell’altro convertono i numeri fratti in numeri interi, eseguono i calcoli sui numeri interi, poi riconvertono i risultati in numeri fratti.
Lualatex sa fare i conti con il linguaggio lua, quindi non mi meraviglio se il suo modo di fare i conti sia più efficiente.
il motore luatex usa la memoria dinamica in automatico? Ahi, ahi ahi; questo può essere utile se chi usa un programma sa quello che sta facendo; può essere disastroso se succede il contrario. Non è un caso se negli anni ’80 c’erano i fautori di C che allocava memoria dinamicamente e i fautori di FORTRAN, non non faceva uso di allocazione dinamica. Entrambi i gruppi avevano buone frecce ai loro archi; ma sulle macchine piccole, quelle disponibili allora, avevano la meglio i fautori di FORTRAN, perché la RAM disponibile era così piccola che era necessario un controllo preciso dell’occupazione della memoria.
Knuth è stato molto cauto nel definire il programma iniziale scritto per essere compilato con Pascal, che in realtà inizialmente era un preprocessore per far eseguire FORTRAN, quindi l’allocazione dinamica era solo simulata. pdftex, il motore di composizione, fa lo stesso: richede una quantità precisa di memoria al sistema operativo e in quella fa quello che viole, apparentemente allocando la memoria che gli serve, ma in realtà non ne può usare un byte in più di quella allocata inizialmente. Lorenzo, io non sono un informatico, ma gli informatici in rete ti possono spiegare meglio quello che ti ho detto da “orecchiante”. Quello che ti posso dire e che ho cercato di sottilineare in questo fileno, è che bisogna fare di tutto per restare nella memoria disponibile, senza chedere nesuuna allocazione dinamica e possibilmente senza chiedere inizialmente nemmeno una grande allocazione statica come si può fare con oggi con texmf.cnf.
[Tommaso que file che hai trovato si trova nel ramo doc della distribuzione, quindi può forse servire a texdoc per fornire qualche informazione sul suo contenuto, ma non viene mai usato dai programmi né di inizializzazione né di composizione, perché il ramo doc non si trova su nessun percorso di ricerca per i file eseguibili suddetti.]
Ciao
Claudio