summaryrefslogtreecommitdiff
path: root/Master/texmf-dist/doc/latex/spectralsequences/manual/spectralsequences-howitworks.tex
diff options
context:
space:
mode:
Diffstat (limited to 'Master/texmf-dist/doc/latex/spectralsequences/manual/spectralsequences-howitworks.tex')
-rw-r--r--Master/texmf-dist/doc/latex/spectralsequences/manual/spectralsequences-howitworks.tex2
1 files changed, 1 insertions, 1 deletions
diff --git a/Master/texmf-dist/doc/latex/spectralsequences/manual/spectralsequences-howitworks.tex b/Master/texmf-dist/doc/latex/spectralsequences/manual/spectralsequences-howitworks.tex
index a4911b459c6..ab2722bd553 100644
--- a/Master/texmf-dist/doc/latex/spectralsequences/manual/spectralsequences-howitworks.tex
+++ b/Master/texmf-dist/doc/latex/spectralsequences/manual/spectralsequences-howitworks.tex
@@ -30,7 +30,7 @@ This is the core idea of the package. In addition to these core features are man
So, having heard this simple description, a reasonable question to ask is: why does it take in excess of 8000 lines of TeX code to accomplish these simple tasks? There are a few reasons. Firstly, the package handles a lot of use cases and has a quite a few different features and there is a large amount of intrinsic complexity to getting these things right. Another huge reason is that \TeX\ is a completely unreasonable coding environment. This is responsible for a good deal of the complexity in \file{sseqparsers}, for example.
-Perhaps the biggest single contributor to code complexity is performance. \tikzname\ is very robust, but it is not fast. \spectralsequences\ draws roughly cubically many classes in large diagrams, and my larger test examples have as many as 5,000 classes. If each class takes an extra millisecond a second to draw, that comes out to an extra five seconds of compilation time. Because of this, unless the performance critical drawing code is super optimized, the package will be way too slow on large diagrams. Most of the added complexity due to performance considerations is contained in \file{sseqdrawing}, but the hard parts of the key value code are all related to performance too.
+Perhaps the biggest single contributor to code complexity is performance. \tikzname\ is very robust, but it is not fast. \spectralsequences\ draws roughly cubically many classes in large diagrams, and my larger test examples have as many as 5,000 classes. If each class takes an extra millisecond to draw, that comes out to an extra five seconds of compilation time. Because of this, unless the performance critical drawing code is super optimized, the package will be way too slow on large diagrams. Most of the added complexity due to performance considerations is contained in \file{sseqdrawing}, but the hard parts of the key value code are all related to performance too.
The last major source of complexity is the robust error handling code. Most \LaTeX\ packages have crappy error handling and result in inscrutable errors even in relatively reasonable use conditions. There are a two main reasons for this as far as I can tell: \LaTeX\ doesn't have good error handling tools and most people who write \LaTeX\ packages are not primarily programmers and have other priorities than ensuring that their packages have clean failure modes. The files \file{sseqmessages} and \file{sseqforeach} are entirely devoted to error handling, and almost all of the complexity of \file{sseqmacromakers} is tied up in error handling too.