# Can TeX generate “heap dumps” to analyze+optimize out-of-memory situations?

As package author of the memory-extensive package pgfplots, I have been asked to analyze some out-of-memory situation.

I could identify the "culprit"; it was some call to \pdfmdfivesum in which it crashed finally.

I am aware of some solutions how to enlarge or avoid memory limits, so please avoid suggestions how to avoid the problem.

My motivation here is: as a software engineer, I wished for some kind of "heap dump" in which I can inspect how much memory is currently being occupied by which "word" or whatever. This could hopefully allow optimizations and systematic improvements; i.e. by clearing unused registers or by restructuring macro expansion or whatever.

Do you know if human-readable heap dumps can be generated?

Here is some more insight into the problem that I tried to address.

Personally, I think that this section is more or less unrelated to the question above: I would really like to hear answers even if there is a simple solution to the problem at hand.

Anyway, if you see how to improve the situation, I would listen carefully.

The problem at hand was the main memory size. Apparently, matlab2tikz generated a 300k file containing a self-contained pgfplots figure along with (lots of!) data points. And the tikz external library attempted to load that file into main memory in order to compute its MD5 hash. This failed. Note that without the MD5 computation, the file could be processed. In fact, the tikz external lib uses \edef\pgfretval{\pdfmdfivesum{\meaning\tikzexternal@temp}} and the call to \meaning fails if \tikzexternal@temp contains these 300k words. I suppose that these words occur more than once in the main memory of TeX; and I would like to learn where and why. This is where I hoped to see a heap dump.

Runaway definition?
->
! TeX capacity exceeded, sorry [main memory size=3000000].
\tikzexternal@hashfct ...aning \tikzexternal@temp
}
l.105 \end{tikzpicture}
%
If you really absolutely need more capacity,
you can ask a wizard to enlarge me.

Here is how much of TeX's memory you used:
18462 strings out of 494578
804304 string characters out of 3169744
3000001 words of memory out of 3000000
21352 multiletter control sequences out of 15000+200000

-
There is no need to load the external file into a macro. \pdfmdfivesum has an optional keyword file that allows the computation of MD5 for an external file. See also \pdf@filemdfivesum of package pdftexcmds that adds support for LuaTeX. –  Heiko Oberdiek Apr 5 '13 at 15:30
@HeikoOberdiek thanks for the note... I considered using that part. However, at that point where I have to compute the MD5, I have already read the file. I would have to generate a tmp file and reread that one (the procedure is triggered at \begin{tikzpicture}). –  Christian Feuersänger Apr 6 '13 at 6:54
Would a LuaTeX solution be OK? I am not sure if it's possible, but in case you'd be OK with a LuaTeX answer I could put some blood into my brain and try to get it to work. –  topskip Apr 24 '13 at 19:05
@topskip Sure, a LuaTeX solution would be fine with me. After all, it would contain the same memory hot spots caused by my package. –  Christian Feuersänger Apr 24 '13 at 19:51
You should not be using \meaning here: it turns something like \relax, a single token, into 7 character tokens, exploding the size. It should cause decidedly less churn to write something like \pdfmdfivesum{\unexpanded\expandafter{\tikzexternal@temp}} to get an appropriate value. That way, one token stays one token, so the memory requirements "only" double. Plus what is taken from the string pool temporarily. With regard to debugging: you can set \tracingstats to a positive value and look at the log file using almost-failing input sizes. Not exactly fabulous. –  user31698 Jun 3 '13 at 19:38

## protected by Community♦May 27 at 9:16

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.