Same issue as pulldown-cmark/pulldown-cmark#832 and jgm/commonmark-hs#145.
The problem is, because the table extension fills in missing table cells, you can force the output to grow as the square of the input by adding one column and one row. This is a side-effect of the extension as specified, and follows from the geometric definition of "squaring": the size of the output is proportional to the area of a square, but the input is proportional to the parameter.
$ python -c 'N=100; print("x|" * N + "\n" + "-|" * N + "\n" + "x|\n" * N)' | ./bin/markdown-it.mjs | wc -c
102362
$ python -c 'N=1000; print("x|" * N + "\n" + "-|" * N + "\n" + "x|\n" * N)' | ./bin/markdown-it.mjs | wc -c
10023062
$ python -c 'N=10000; print("x|" * N + "\n" + "-|" * N + "\n" + "x|\n" * N)' | ./bin/markdown-it.mjs | wc -c
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memoryThe output size grows roughly as square of the input size: factor of 10 growth on input means factor of 100 growth on output.
cmark-gfm avoids this problem by putting a limit on the number of cells it will "autocomplete." md4c simply limits the number of columns.
Same issue as pulldown-cmark/pulldown-cmark#832 and jgm/commonmark-hs#145.
The problem is, because the table extension fills in missing table cells, you can force the output to grow as the square of the input by adding one column and one row. This is a side-effect of the extension as specified, and follows from the geometric definition of "squaring": the size of the output is proportional to the area of a square, but the input is proportional to the parameter.
The output size grows roughly as square of the input size: factor of 10 growth on input means factor of 100 growth on output.
cmark-gfm avoids this problem by putting a limit on the number of cells it will "autocomplete." md4c simply limits the number of columns.