CoCoA » CoCoA-5

I have tried doing some profiling. The interpreter takes quadratic time (in the number of terms) to read a polynomial from its printed form, i.e. as a sum of terms.

Somewhat ironically, for polynomials with many terms it is significantly faster to read them as a string and then use ReadExpr to convert it into a ring element. The point here is that ReadExpr knows to expect a ring element whereas the interpreter has to be able to cope with expressions of any type.

An ideal situation would be to have the parser generate n-ary nodes for sums. I've no idea how hard this might be; it would certainly involve some "deep" changes to the parse tree structure, and also the interpreter.

An alternative would be to hack the interpreter so that it uses geobuckets when summing values in a polynomial ring. This might be quite messy and fiddly to get right :-/

The solution to use ReadExpr(P, "poly-as-a-string") works tolerably well from the point of view of the interpreter, but it is insufferably slow inside emacs if the string is a long literal (today's example was 20Mbytes long).

The problem is that emacs gets too slow when there are long lines. Note that changing from cocoa5-mode to fundamental-mode in emacs did help a bit, but it was still far too slow. Should we revitalize issue #576? (about allowing juxtaposition of string literals to cause the parser to concatenate them)

A better workaround is to use sum([...]).
I have just tried a test of the form:

substr := "some substring"; --> loer in my test
str := substr+substr+ ... (about 10000 summands) + substr; --> took about 2s
str := sum([substr, substr, ... (same number of summands), substr]); --> took about 0.3s

So a tolerable workaround is to split the string into substrings which are placed in a list, and then use sum to concatenate them.

This issue is really about two problems: CoCoA's quadratic behaviour reading a poly directly, Emacs's slow behaviour on long lines.