☰

texlive 2016 및 Forest 2.0으로 마이그레이션한 후 메모리 문제

tag-icon • tag-icon xetex forest memory texlive-2016
texlive 2016 및 Forest 2.0으로 마이그레이션한 후 메모리 문제

나는 800페이지가 넘는 책을 가지고 있으며 texlive 2015에서 xelatex 및 Forest 1.05로 잘 컴파일됩니다. 내 번역가가 Forest 2.0에서 작업하므로 texlive 2016으로 마이그레이션하고 있습니다. 이제 나는 다음을 얻습니다:

! TeX capacity exceeded, sorry [pool size=6143546].
\safeiterate@4 ...@countc y\endcsname )\endcsname 
                                              \forest@inpath      \forest@tem...
l.770 }

산림 코드를 제거하면 나중에 오류가 발생합니다. 더 작은 부분을 텍스트로 처리하면 모든 것이 괜찮습니다. 그래서 정말 기억력 문제인 것 같아요.

질문: 일부 tex 구성 파일을 수정하는 것 외에 제가 할 수 있는 일이 있나요? 코드는 여러 사용자에 대해 실행되어야 하며 메모리 변수를 수정해야 하는 것은 좋지 않습니다.

죄송합니다. 여기에는 최소한의 예가 없지만 github이나 다른 곳에서 코드를 사용할 수 있도록 할 수 있습니다.

편집 : 알았어. texlive 2016을 실행하는 동안 포리스트 1.05를 로드하면 모든 것이 정상이므로 포리스트 2.0이어야 합니다.

답변1

이것은 실제로 숲 문제였지만 놀랍게도 패키지의 첫 번째 버전부터 존재했습니다. Stefan은 이렇게 길고 나무가 가득한 문서를 만든 최초의 사람이었습니다. v1에서 v2로의 전환은 문제를 극한으로 밀어붙일 뿐이었습니다.

무엇이 잘못되었는지 설명하기 전에: 방금 CTAN에 수정된 버전(v2.1.4)을 게시했습니다.

문제는 바로 Ulrike Fischer가 위의 의견에서 언급한 내용이었습니다. Forest의 패킹 알고리즘은 좌표(및 좌표 쌍)에 대한 일부 정보를 (일시적으로) 저장해야 합니다. 게다가 좌표(또는 쌍)가 주어지면 이에 대한 정보를 빠르게 검색해야 합니다. 확실한 해결책은 좌표를 조회 키로 사용하여 정보를 사전(연관 배열)에 저장하는 것입니다. 따라서 TeX의 제어 시퀀스를 사용하는 것이 완벽한 아이디어처럼 보였고 저는 순진하게 그렇게 했습니다(본질적으로 개념 증명 Python 구현에서 복사하여 붙여넣었습니다). ):

\csdef{forest@(\the\pgf@x,\the\pgf@y)}{...}

그리고 심지어

\csdef{forest@(\the\pgf@xa,\the\pgf@ya)--(\the\pgf@xb,\the\pgf@yb)}{...}

정의가 로컬이지만 항목이 TeX의 해시 테이블에 영원히 남아 있다는 사실을 깨닫지 못합니다. 이 접근 방식은 몇 킬로바이트의 문자열 풀 공간을 쉽게 소모했습니다.나무당!

v2.1.4는 모든 정보를 단일 toks 레지스터에 저장하여 문제가 되는 사전을 다시 구현합니다. 그 내용은 다음과 같습니다(위 문제 중 첫 번째 문제에만 표시됨).

...(x1,y1){...}(x2,y2){...}...

이러한 구조에서는 특정 좌표를 검색하는 것이 쉽습니다(비록 \csname접근 방식보다 느리긴 하지만).

\def\forest@breakpath@getfromtoks#1#2#3#4{%
  % #1=cache toks register, #2=receiving cs, (#3,#4)=point;
  % we rely on the fact that the point we're looking up should always be present
  \def\forest@breakpath@getfromtoks@##1(#3,#4)##2##3\forest@END{##2}%
  \edef#2{\expandafter\forest@breakpath@getfromtoks@\the#1\forest@END}%

(많은 패키지가 이러한 시스템을 사용합니다 \pgfutil@in@. 예를 들어\ PGF 참조)

새 시스템은 약 10% 느리지만 Stefan의 800페이지가 넘는 책에서 버전 v2.1.3이 600만 개의 문자열 풀 제한을 초과한 경우 v2.1.4(및 로드된 다른 모든 패키지)는 200만 개에 불과한 양을 사용합니다. . 패킹 알고리즘에 의한 메모리 소비와 관련하여 문서 길이는 더 이상 중요하지 않습니다.

스테판님, 지난 주 동안 이 책을 찾아주시고 함께해주셔서 감사합니다! (힌트: 몇 년 후에 패킹 알고리즘을 다시 살펴보면 훨씬 더 빨라질 수도 있다고 생각합니다!)

관련 정보