CoCoA » CoCoA-5

I hope this evening to try compiling again on the small computer, and I'll note which files gave problems with swapping.

Other compilation times:

BIF-GSL    88s
BIF-Norm   81s
BIF-other  60s about

Do you know how much the overhead for including library.H is? that is quite slow by itself.
(try compiling an examples/ex-XXX)

I have just checked (using fgrep) and in BuiltinFunctions-CoCoALib.C there are 28 fns with variable arity, and 129 with fixed arity. So if we use this criterion to split the file, the split will be quite uneven (but it might already make an improvement).

John Abbott wrote:

I have just checked (using fgrep) and in BuiltinFunctions-CoCoALib.C there are 28 fns with variable arity, and 129 with fixed arity. So if we use this criterion to split the file, the split will be quite uneven (but it might already make an improvement).

True, it is uneven, but it'd make life easier for making new variable-arity functions ;-)

John Abbott wrote:

BTW I noticed that it took quite a long time to compile BuiltinFunctions-Normaliz.C even though Normaliz was absent -- this must surely be wrong!

if a library is missing we define the missing functions by

  DECLARE_MISSING_EXTLIB(NmzXXXXX, "NORMALIZ")

Here are the compilations timings for the updated computer:

Compiling AST.o
real    0m54.451s
user    0m42.212s

Compiling Lexer.o
real    0m48.666s
user    0m37.980s

Compiling Interpreter.o
real    3m46.070s
user    2m27.732s

Compiling Parser.o
real    1m2.698s
user    0m59.264s

Compiling BuiltInFunctions.o
real    1m25.513s
user    1m16.468s

Compiling BuiltInFunctions-CoCoALib.o
real    3m9.038s
user    2m6.824s

Compiling BuiltInOneLiners-CoCoALib.o
real    2m8.872s
user    1m44.848s

Compiling BuiltInFunctions-Frobby.o
real    0m53.534s
user    0m35.624s

I have arbitrarily excluded those which took less than 40 sec real time.
Anyway, the slow compilations are clear: Interpreter.C, BuiltinFunctions-CoCoALib.C and BuiltinOneLiners-CoCoALib.C

I tried compiling some examples: it takes about 15-20s to compile and link an example (actually ex-empty took longer than ex-matrix1... very odd!)

I note also that my compilation test above was without any external libraries.
So the time to compile BuiltinFunctions-Frobby.C is the time to make the "empty" version!!

It seems that many includes in BuiltInFunctions.H are useless, or useful for only a few functions. Cleaning them might help! (experimenting)

I suggest putting DECLARE_MISSING_EXTLIB into a smaller header file (if possible).

Then files such as BuiltinFunctions-Frobby.C can be something like:

#include "CoCoA/PREPROCESSOR_DEFNS.H" 

#if !defined(CoCoA_WITH_FROBBY)

#include "MissingExtlib.H" 
  DECLARE_MISSING_EXTLIB(FrbDimension, "FROBBY")
  ....

#else

  #include "BuiltinFunctions.H" 
  #include "BuiltinOneLiners.H" 

  ... usual code ...
#endif

This should enable almost instant compilation when CoCoA_WITH_FROBBY is not defined.

John Abbott wrote:

I am very tempted to suggest modifying the macro DECLARE_MISSING_EXTLIB so that it is independent of the other DECLARE_XYZ macros. The disadvantage is that there will be slight duplication of the "internal interface"; but since I do not expect we will ever change this, the duplication is not really a problem (but it must be clearly documented... just in case some does change it).

I get VERY anxious about duplicating code.
I've noticed, and tested, that many includes in BuiltInFunctions.H are useful only for some file. This is no wonder, as we originally had everything in BuiltinFunctions.C.
I think we should start by cleaning and reorganizing the code before anything else.

As a start, CoCoALibSupplement is no longer included in ExtLib BuiltInFunction-XXX.C files.

Indeed "duplication" is generally undesirable (as is the use of goto), but it may still be a good idea in certain "unusual" circumstances (as can a goto command).

Removing unnecessary includes is certainly a good idea, but in this case I believe it is a separate issue. The definitions of the functions which report that Normaliz is not present should require (almost?) no includes.

I think that the current implementation is poor because the code itself is misleading: it uses the mechanism for defining a "normal" builtin function, but actually wants to define a "special" function.

I believe that built-in functions (for extlibs, at least) are "registered" by constructing a global object. So the actual registration is performed by the ctor calls for these objects (the objects themselves do nothing).

An idea is to create a second ctor for these objects which can be called just with the string "Normaliz not present".

The object type is AddBuiltIn. Its ctor is in BuiltinFunctions.H around line 120.

Anna has just sent me some code with redundant #include directives removed.
Most compilation times are the same. There were two improvements: Lexer.C compiles now in 40s (previously 48s), and BuiltinFunctions-CoCoALib.C compiles in 150s (previously 190s).