Reading through pi.tex, I discovered the trick of using \fontdimen as an array of dimensions (which is equivalent to storing integers between ±(2^31-1)sp). Namely,
\font\x=cmr10 at 1sp % or whatever font that is not used in the document.
\fontdimen 10000 \x = 1pt
\showthe\fontdimen 10000 \x % => 1pt
\bye
This method of storage appears to be very efficient memory-wise (in TeXLive 2012, pdfTeX and XeTeX are happy to store a bit less than 3000000 such parameters, LuaTeX extends memory as needed), and speed-wise (I benchmarked access and modification to be just as fast as for usual dimen registers, once the space has been allocated).
The main drawback I see is that the size of the array must be declared as soon as the new font is introduced (or rather, before another font is defined):
\font\x=cmr10 at 1sp
\font\y=cmr10 at 2sp
\fontdimen1000\x=1pt % => error: '\x only has 7 fontdimen parameters'
\bye
Are there any other drawbacks to using font memory for the storage of large amounts of data? Is it frequent for a document to reach the bounds of […]TeX's font memory (in which case I shouldn't use it for other purposes than fonts)? If not, I am thinking of using this technique for l3regex, and perhaps to store some tables of values for l3fp.
\fontdimenparameters are used for, except for that trick. Should I ask a separate question? Also, there may be a risk that the values of those parameters are included in the resulting pdf? – Bruno Le Floch Jan 28 '13 at 15:50tex.webI see another potential pitfall: the extra fontdimen parameters are included in the format. For l3regex I would be using the fontdimen parameters as (global) scratch space, which means that l3regex should not be used to help setting up the kernel (not much of a problem, I guess). – Bruno Le Floch Jan 30 '13 at 08:53l3regexinto the kernel at some point simply to avoid the 'now load X' business you have in LaTeX2e: easier if all of these things are 'out of the box'. That said, I'm not clear on how we might div up 'thinks in a format file' and 'thinks loaded after the format file'. – Joseph Wright Jan 30 '13 at 08:55l3regexin the format file won't be a problem in this approach, but runningl3regexfunctions before dumping would be a problem. I don't see us needing those functions to construct kernel-level things. – Bruno Le Floch Jan 30 '13 at 09:03