On Tue, Jul 26, 2022 at 07:47:05PM +0800, Qian Yun wrote:
> My idea is to just skip compile (some) lisp file during
> database generation stage, similar to the "$SaveParseOnly"
> variable.

Well, AFAICS in principle there is no need to compile categories.
More precisely, Spad category has two part: proper category
and default package.  Default package more or less should
be handled like other domains and packages.  OTOH proper
categories are quite different from other constructors.
In particular currently categories are evaluated during
typechecking so we need runnable code for categories at
quite erarly stages.  But we should be able to re-organize
compiler representation of types so that categories are
pure data.  This date could be initialized in lazy way
which hopefully could get rid of one pass from stamp_db
stage.  And code for categories calls eval and few other
things like JoinInner.  My profile data indicates
that Lisp eval takes about 12% of stamp_db stage
(sb-fasteval does not make significant difference here).

So better handling of categories could save both time
compiling Lisp files and probably also lead to
savings during normal Spad compilations.

Also, currently there are two reasons to compile Spad
files before main compilation:
1) we need compiled code for inlining.  For this
   purpose actually all we need is data (Lisp forms).
   Compiling is useful to speed up loading of this
   info, but we do not need most of generated code
   and in principle we could load data in different way.
2) When evaluating categories we need to evaluate some
   types appearing is categories (I did not work out
   exact rules).  Keeping types as data in principle
   could avoid need for early compilation.  Again
   we need to solve problem of efficiently loading
   needed data during main compile.

-- 
                              Waldek Hebisch

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20220726185823.GB9154%40fricas.math.uni.wroc.pl.

Reply via email to