Jonathan Sauer wrote:
there is no control over the lua end of the game; also, when using much data, in practice the garbage collectors will bring down your system (so slow that one will abort the job);
Interesting. In what use cases did you observe this behaviour?
extensive use of the token callback is one i remember, and a previous implementation of node callbacks passes tables instead of userdata which was also slow (has to do with the moment the collector steps in); by now i have developped a kind of feeling where/how to speed up things
luatex kind of assumes modern memory management
This is surely a given, since LuaTeX runs on Unix and Windows.
and machines with memort in the gig range
This I think is a bit optimistic and IMO limits the usefulness of LuaTeX. Especially since TeX has much lower requirements.
sure, but luatex is not tex; for large jobs (say a couple of hundred pages with many advanced open type fonts, many graphics, color, hyperlinks or whatever takes memory) topping at of 400-500 meg is not uncommon and given todays machines we find that acceptable; it also depends on what kind of trickery one does
The problem is not caching, but that LuaTeX, when accessing the bytecode register, has overwritten almost all memory (the first 12 bytes of each 16 byte block) with zeros. This is the result of the buffer overflow.
sure, and that need to be fixed; however, the kind of message (and controling that) is for later hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------