fricas on ECL on windows

[Qian Yun]

I've made fricas build with ECL on windows in CI a while ago,
but today it's my first time to try to run the binary myself.

I just made a commit to make it work. On windows, the "cmp"
module does not exist by default, (in CI it comes from build
directory), if we don't load it, I've confirmed the bytecode
compiler works.

After that, the immediate problem: anti virus program.

Since ECL compiles each domain into a separate executable,
loading each of them will trigger a virus scan, cost a few seconds,
or over ten seconds if "cloud based threat detection" is enabled.

That means computing a simple integral can take minutes for the
first try.

I suggest we add an extra build mode that builds a single executable,
instead of 1400+.

It should also reduce the build size, because of all these duplicated
PE headers. (On windows, ecl build is over 100MB while sbcl build
is 34MB.)

BTW, for cygwin build, I'm still trying to figure out why the build
takes 3 hours and "make check" takes 2 hours. The mingw64 build
takes 1 hours and "make check" takes 3 minutes, for comparison.

- Qian

[Waldek Hebisch]

On Tue, Jul 21, 2026 at 09:41:44PM +0800, Qian Yun wrote:
> I've made fricas build with ECL on windows in CI a while ago,
> but today it's my first time to try to run the binary myself.
>
> I just made a commit to make it work. On windows, the "cmp"
> module does not exist by default, (in CI it comes from build
> directory), if we don't load it, I've confirmed the bytecode
> compiler works.

Last time that I looked at ECL related problem I was told
that ECL FFI constructs only work in compiled code. Did
this change?

> After that, the immediate problem: anti virus program.
>
> Since ECL compiles each domain into a separate executable,
> loading each of them will trigger a virus scan, cost a few seconds,
> or over ten seconds if "cloud based threat detection" is enabled.
>
> That means computing a simple integral can take minutes for the
> first try.

That is problem not only for FriCAS. People running antivirus
seem to be used to it.

> I suggest we add an extra build mode that builds a single executable,
> instead of 1400+.

That would add considerable complexity to the build system and
probably would increase space use.

> It should also reduce the build size, because of all these duplicated
> PE headers. (On windows, ecl build is over 100MB while sbcl build
> is 34MB.)

Current build process depends on ability to load freshly compiled
files. During compilation we load categories and core domains.
Database build loads everything.

> BTW, for cygwin build, I'm still trying to figure out why the build
> takes 3 hours and "make check" takes 2 hours. The mingw64 build
> takes 1 hours and "make check" takes 3 minutes, for comparison.

Hmm, maybe 'fork'? Fork emulation on cygwin is rather expensive.
--
Waldek Hebisch

[Dima Pasechnik]

On July 21, 2026 11:52:05 AM CDT, Waldek Hebisch <de...@fricas.org> wrote:
>On Tue, Jul 21, 2026 at 09:41:44PM +0800, Qian Yun wrote:
>> I've made fricas build with ECL on windows in CI a while ago,
>> but today it's my first time to try to run the binary myself.
>>
>> I just made a commit to make it work. On windows, the "cmp"
>> module does not exist by default, (in CI it comes from build
>> directory), if we don't load it, I've confirmed the bytecode
>> compiler works.
>
>Last time that I looked at ECL related problem I was told
>that ECL FFI constructs only work in compiled code. Did
>this change?
>
>> After that, the immediate problem: anti virus program.
>>
>> Since ECL compiles each domain into a separate executable,
>> loading each of them will trigger a virus scan, cost a few seconds,
>> or over ten seconds if "cloud based threat detection" is enabled.
>>
>> That means computing a simple integral can take minutes for the
>> first try.
>
>That is problem not only for FriCAS. People running antivirus
>seem to be used to it.
>
>> I suggest we add an extra build mode that builds a single executable,
>> instead of 1400+.
>
>That would add considerable complexity to the build system and
>probably would increase space use.

I don't know how different Fricas build is from Maxima build, but we added such a target, which makes a single maxima.fas file, loadable in ecl
by "(require :maxima)", it wasn't something complex.

Also, having such a fas file allows embedding Fricas as a Python module, something we use to interface with Maxima (and Kenzo, another Lisp program which does algebraic topology).

>
>> It should also reduce the build size, because of all these duplicated
>> PE headers. (On windows, ecl build is over 100MB while sbcl build
>> is 34MB.)
>
>Current build process depends on ability to load freshly compiled
>files. During compilation we load categories and core domains.
>Database build loads everything.
>
>> BTW, for cygwin build, I'm still trying to figure out why the build
>> takes 3 hours and "make check" takes 2 hours. The mingw64 build
>> takes 1 hours and "make check" takes 3 minutes, for comparison.
>
>Hmm, maybe 'fork'? Fork emulation on cygwin is rather expensive.

Yes, we used to build Sage (including ecl and Maxima) on Cygwin, and it was taking like 5 time more time than such a build on Linux.
Ecl uses fork, which is very flaky on Cygwin, and we had to repeatedly do rebasing during builds.

Dima

[Qian Yun]

On 7/22/26 12:52 AM, Waldek Hebisch wrote:
> On Tue, Jul 21, 2026 at 09:41:44PM +0800, Qian Yun wrote:
>> I've made fricas build with ECL on windows in CI a while ago,
>> but today it's my first time to try to run the binary myself.
>>
>> I just made a commit to make it work. On windows, the "cmp"
>> module does not exist by default, (in CI it comes from build
>> directory), if we don't load it, I've confirmed the bytecode
>> compiler works.
>
> Last time that I looked at ECL related problem I was told
> that ECL FFI constructs only work in compiled code. Did
> this change?

I guess no. To be clear: during building fricas, "cmp" and
c compiler is still used. But when delivering the final
binary to end user's computer, "cmp" and c compiler is disabled,
and user can use bytecode compiler to do ")compiler xxx.spad".

>> After that, the immediate problem: anti virus program.
>>
>> Since ECL compiles each domain into a separate executable,
>> loading each of them will trigger a virus scan, cost a few seconds,
>> or over ten seconds if "cloud based threat detection" is enabled.
>>
>> That means computing a simple integral can take minutes for the
>> first try.
>
> That is problem not only for FriCAS. People running antivirus
> seem to be used to it.

People get used to antivirus program, but people does not get used
to one application containing 1400+ binaries waiting to be scanning.

>> I suggest we add an extra build mode that builds a single executable,
>> instead of 1400+.
>
> That would add considerable complexity to the build system and
> probably would increase space use.
>
>> It should also reduce the build size, because of all these duplicated
>> PE headers. (On windows, ecl build is over 100MB while sbcl build
>> is 34MB.)
>
> Current build process depends on ability to load freshly compiled
> files. During compilation we load categories and core domains.
> Database build loads everything.
>

I mean, don't change build step much, only change the final binary.
I tried before that concat 1400+ lsp file into one and compile
to one single fas file.

Also, this approach can help fricas on ecl on wasm, because loading
domains one by one via network is too slow. Loading all domains
at once is faster.

- Qian

[Qian Yun]

On 7/22/26 1:24 AM, Dima Pasechnik wrote:
>
>
>
>
> I don't know how different Fricas build is from Maxima build, but we added such a target, which makes a single maxima.fas file, loadable in ecl
> by "(require :maxima)", it wasn't something complex.
>
> Also, having such a fas file allows embedding Fricas as a Python module, something we use to interface with Maxima (and Kenzo, another Lisp program which does algebraic topology).
>
>

Maxima can be built as pure lisp via ASDF. FriCAS does not support
that yet. This option can be explored.

>
>
>>
>>> It should also reduce the build size, because of all these duplicated
>>> PE headers. (On windows, ecl build is over 100MB while sbcl build
>>> is 34MB.)
>>
>> Current build process depends on ability to load freshly compiled
>> files. During compilation we load categories and core domains.
>> Database build loads everything.
>>
>>> BTW, for cygwin build, I'm still trying to figure out why the build
>>> takes 3 hours and "make check" takes 2 hours. The mingw64 build
>>> takes 1 hours and "make check" takes 3 minutes, for comparison.
>>
>> Hmm, maybe 'fork'? Fork emulation on cygwin is rather expensive.
>
> Yes, we used to build Sage (including ecl and Maxima) on Cygwin, and it was taking like 5 time more time than such a build on Linux.
> Ecl uses fork, which is very flaky on Cygwin, and we had to repeatedly do rebasing during builds.
>
> Dima
>

Just tried my self, the computation is indeed very slow, over 10x.
The above "make check" difference is 40x. It can't be explained
by slow "fork". I didn't profile or debug deeper.
Just note it here that people should avoid fricas on ecl on cygwin
when possible.

- Qian

[Dima Pasechnik]

On Tue, Jul 21, 2026 at 7:00 PM Qian Yun <oldk...@gmail.com> wrote:
>
> On 7/22/26 1:24 AM, Dima Pasechnik wrote:
> >
> >
> >
> >
> > I don't know how different Fricas build is from Maxima build, but we added such a target, which makes a single maxima.fas file, loadable in ecl
> > by "(require :maxima)", it wasn't something complex.
> >
> > Also, having such a fas file allows embedding Fricas as a Python module, something we use to interface with Maxima (and Kenzo, another Lisp program which does algebraic topology).
> >
> >
>
> Maxima can be built as pure lisp via ASDF. FriCAS does not support
> that yet. This option can be explored.
>

I don't know what "pure lisp" means here.
What's the difference between https://github.com/oldk1331/fricas0
and "standard" Fricas?
I understand Fricas language (spad?) runs on top of a Lisp, just as
Maxima's language runs on top of a Lisp.
But perhaps it's not quite so.

> >
> >
> >>
> >>> It should also reduce the build size, because of all these duplicated
> >>> PE headers. (On windows, ecl build is over 100MB while sbcl build
> >>> is 34MB.)
> >>
> >> Current build process depends on ability to load freshly compiled
> >> files. During compilation we load categories and core domains.
> >> Database build loads everything.
> >>
> >>> BTW, for cygwin build, I'm still trying to figure out why the build
> >>> takes 3 hours and "make check" takes 2 hours. The mingw64 build
> >>> takes 1 hours and "make check" takes 3 minutes, for comparison.
> >>
> >> Hmm, maybe 'fork'? Fork emulation on cygwin is rather expensive.
> >
> > Yes, we used to build Sage (including ecl and Maxima) on Cygwin, and it was taking like 5 time more time than such a build on Linux.
> > Ecl uses fork, which is very flaky on Cygwin, and we had to repeatedly do rebasing during builds.
> >
> > Dima
> >
>
> Just tried my self, the computation is indeed very slow, over 10x.
> The above "make check" difference is 40x. It can't be explained
> by slow "fork". I didn't profile or debug deeper.
> Just note it here that people should avoid fricas on ecl on cygwin
> when possible.
>
> - Qian
>

> --
> 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 fricas-devel...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/19c57c26-0532-4b84-89c8-46e62e546f0d%40gmail.com.

[Qian Yun]

On 7/22/26 8:15 AM, Dima Pasechnik wrote:
>>
>> Maxima can be built as pure lisp via ASDF. FriCAS does not support
>> that yet. This option can be explored.
>>
> I don't know what "pure lisp" means here.
> What's the difference between https://github.com/oldk1331/fricas0
> and "standard" Fricas?
> I understand Fricas language (spad?) runs on top of a Lisp, just as
> Maxima's language runs on top of a Lisp.
> But perhaps it's not quite so.
>

"Pure lisp" build means lacking a few FFI C functions, especially
socket functions, so no communication with C components: hyperdoc,
graphics.

fricas0 is pure lisp, but not via ASDF, unlike maxima:
https://github.com/calyau/maxima/blob/master/src/maxima.asd

So compiling fricas into one single file is not as straight forward
as maxima.

- Qian

[Dima Pasechnik]

On Tue, Jul 21, 2026 at 7:45 PM Qian Yun <oldk...@gmail.com> wrote:
>
> On 7/22/26 8:15 AM, Dima Pasechnik wrote:
> >>
> >> Maxima can be built as pure lisp via ASDF. FriCAS does not support
> >> that yet. This option can be explored.
> >>
> > I don't know what "pure lisp" means here.
> > What's the difference between https://github.com/oldk1331/fricas0
> > and "standard" Fricas?
> > I understand Fricas language (spad?) runs on top of a Lisp, just as
> > Maxima's language runs on top of a Lisp.
> > But perhaps it's not quite so.
> >
>
> "Pure lisp" build means lacking a few FFI C functions, especially
> socket functions, so no communication with C components: hyperdoc,
> graphics.
>
> fricas0 is pure lisp, but not via ASDF, unlike maxima:
> https://github.com/calyau/maxima/blob/master/src/maxima.asd

isn't it more or less trivial to create fricas.asd ?
Basically, listing files into appropriate slots, no?

>
> So compiling fricas into one single file is not as straight forward
> as maxima.
>
> - Qian
>

> --
> 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 fricas-devel...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/99f1e6c8-927f-4d04-9355-f237262c5cbf%40gmail.com.

[Qian Yun]

On 7/22/26 10:06 AM, Dima Pasechnik wrote:
> On Tue, Jul 21, 2026 at 7:45 PM Qian Yun <oldk...@gmail.com> wrote:
>>
>> On 7/22/26 8:15 AM, Dima Pasechnik wrote:
>>>>
>>>> Maxima can be built as pure lisp via ASDF. FriCAS does not support
>>>> that yet. This option can be explored.
>>>>
>>> I don't know what "pure lisp" means here.
>>> What's the difference between https://github.com/oldk1331/fricas0
>>> and "standard" Fricas?
>>> I understand Fricas language (spad?) runs on top of a Lisp, just as
>>> Maxima's language runs on top of a Lisp.
>>> But perhaps it's not quite so.
>>>
>>
>> "Pure lisp" build means lacking a few FFI C functions, especially
>> socket functions, so no communication with C components: hyperdoc,
>> graphics.
>>
>> fricas0 is pure lisp, but not via ASDF, unlike maxima:
>> https://github.com/calyau/maxima/blob/master/src/maxima.asd
>
> isn't it more or less trivial to create fricas.asd ?
> Basically, listing files into appropriate slots, no?
>

Maybe, maybe not. I haven't tried. I guess the dependency
among lisp files should be specified, that could be a problem.

I can give it a try soon.

- Qian

[Dima Pasechnik]

perhaps https://github.com/oldk1331/fricas0/pull/1 is useful (it's not working)

> - Qian
>
> --
> 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 fricas-devel...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/54d325c8-9fb2-4964-be7a-0bb7635edf38%40gmail.com.

[Waldek Hebisch]

At first glance main work should be scanning given volume of
executable code. It should not make much difference if the
code is in single piece or in several pieces.

Concerning many parts, various plugin architectures seem to be
quite popular, mayby not with 1400 parts, but certainly with
hundreds.

But if you have data showing that having code in one piece helps
then we can try to do something.

> >> I suggest we add an extra build mode that builds a single executable,
> >> instead of 1400+.
> >
> > That would add considerable complexity to the build system and
> > probably would increase space use.
> >
> >> It should also reduce the build size, because of all these duplicated
> >> PE headers. (On windows, ecl build is over 100MB while sbcl build
> >> is 34MB.)
> >
> > Current build process depends on ability to load freshly compiled
> > files. During compilation we load categories and core domains.
> > Database build loads everything.
> >
> I mean, don't change build step much, only change the final binary.
> I tried before that concat 1400+ lsp file into one and compile
> to one single fas file.

OK, making "algebra fas" on FriCAS side should be relatively
strigtforward, we have list of all NRLIB-s and there is question
of "linking" them. The question is how well ECL suports it. In
a sense it is just linking many object files. But there is some
magic on ECL side, for example ECL wants to run init routines in
each object files. So basically it is question of ECL.

When building interpreter with ECL we use modified compile command,
so that we get linkable files. In algebra we use normal command
so that we get loadable .fas. In principle we could try third
command that produces both.

Another thing is using such a .fas. One way is to load it at
startup, but I am not sure if this would work well (once you
clear LOADED property on NRLIB name FriCAS will try to load
it second time).

> Also, this approach can help fricas on ecl on wasm, because loading
> domains one by one via network is too slow. Loading all domains
> at once is faster.

Is it really? IIUC connection setup takes some time, but once
set up connection can transfer hundreds of files. Also, typical
FriCAS run should only use part of algebra, not the whole. So
there is less data to transfer and less compute time spend in
LOAD.

--
Waldek Hebisch

[Qian Yun]

On 7/22/26 9:50 PM, Waldek Hebisch wrote:
>
> At first glance main work should be scanning given volume of
> executable code. It should not make much difference if the
> code is in single piece or in several pieces.
>

No, the virus scanning is done on each and every binary load.

> Concerning many parts, various plugin architectures seem to be
> quite popular, mayby not with 1400 parts, but certainly with
> hundreds.
>
> But if you have data showing that having code in one piece helps
> then we can try to do something.
>

Just thought of another benefit:

If we have a single binary, then it will have a larger ".text"
section, will cost more memory than load-on-demand version,
but when running multiple FRICASsys processes in parallel,
that could save memory because ".text" section will be shared,
but '(load "xxx.fasl")' will consume heap memory and will not be
shared.

>> Also, this approach can help fricas on ecl on wasm, because loading
>> domains one by one via network is too slow. Loading all domains
>> at once is faster.
>
> Is it really? IIUC connection setup takes some time, but once
> set up connection can transfer hundreds of files. Also, typical
> FriCAS run should only use part of algebra, not the whole. So
> there is less data to transfer and less compute time spend in
> LOAD.
>

Yes, because we load each domain one by one, not in parallel.
(Only after loading domainA, we know its dependencies.)
Then the IOPS over network is significantly worse than disks.
Even if downloading a domain needs 100ms (TCP 3 way handshake),
doing integral requiring dozens of domains, costing seconds
just to download them. While in the mean time, loading 1400+
domains in a single binary, only cost seconds as well.

- Qian

[Waldek Hebisch]

On Thu, Jul 23, 2026 at 01:56:21PM +0800, Qian Yun wrote:
> On 7/22/26 9:50 PM, Waldek Hebisch wrote:
> >
> > At first glance main work should be scanning given volume of
> > executable code. It should not make much difference if the
> > code is in single piece or in several pieces.
> >
>
> No, the virus scanning is done on each and every binary load.

But the question is how much time does it take. Single 10Gb binary
is likely to take long time simply because this is a lot of code
to scan. If you have measured time needed in both cases, then
we would know. But without measurement it is just guessing.
And of course time will depend on specific antivirus program
in use.

> > Concerning many parts, various plugin architectures seem to be
> > quite popular, mayby not with 1400 parts, but certainly with
> > hundreds.
> >
> > But if you have data showing that having code in one piece helps
> > then we can try to do something.
> >
>
> Just thought of another benefit:
>
> If we have a single binary, then it will have a larger ".text"
> section, will cost more memory than load-on-demand version,
> but when running multiple FRICASsys processes in parallel,
> that could save memory because ".text" section will be shared,
> but '(load "xxx.fasl")' will consume heap memory and will not be
> shared.

There will be some saving. But ECL .fas is just a shared library
and code in shared libraries is shared between processes. We
will probably save a bit on relocatations. But note that ECL
creates at runtime many things that are logically constant
(say a big immutable list). So there will be extra runtime
and extra memory use from files which are unused but included
in the executable.

> >> Also, this approach can help fricas on ecl on wasm, because loading
> >> domains one by one via network is too slow. Loading all domains
> >> at once is faster.
> >
> > Is it really? IIUC connection setup takes some time, but once
> > set up connection can transfer hundreds of files. Also, typical
> > FriCAS run should only use part of algebra, not the whole. So
> > there is less data to transfer and less compute time spend in
> > LOAD.
> >
>
> Yes, because we load each domain one by one, not in parallel.
> (Only after loading domainA, we know its dependencies.)

Web browsers are supposed to handle this. Browser first loads
a page, parses it and only after that knows what more is needed.
The loaded files can recursively load more things. If all
this works as designed the whole cascade will be loaded via
single connection.

So, dependencies alone do not exclude reusing the same connection.

> Then the IOPS over network is significantly worse than disks.
> Even if downloading a domain needs 100ms (TCP 3 way handshake),
> doing integral requiring dozens of domains, costing seconds
> just to download them. While in the mean time, loading 1400+
> domains in a single binary, only cost seconds as well.

This is question of balace between bandwidth and latency.
And possibly question of loading strategy. IIUC web
version currently uses simple strategy of downloading a domain
when FriCAS wants to load it. But we can predict with
rather high probablity that after loading one domain some
other will be loaded too. So we could initiate downloading
much earlier.

In fact, in web version it probably would make sense to exclude
Spad compiler and some other pieces to reduce size of main
file.

Maybe you have better data, but when I tried web version it
took a lot of time to get to the first prompt, which should be
just loading a single file.

--
Waldek Hebisch

[Qian Yun]

On 7/26/26 7:57 AM, Waldek Hebisch wrote:
>>
>> Just thought of another benefit:
>>
>> If we have a single binary, then it will have a larger ".text"
>> section, will cost more memory than load-on-demand version,
>> but when running multiple FRICASsys processes in parallel,
>> that could save memory because ".text" section will be shared,
>> but '(load "xxx.fasl")' will consume heap memory and will not be
>> shared.
>
> There will be some saving. But ECL .fas is just a shared library
> and code in shared libraries is shared between processes. We
> will probably save a bit on relocatations. But note that ECL
> creates at runtime many things that are logically constant
> (say a big immutable list). So there will be extra runtime
> and extra memory use from files which are unused but included
> in the executable.
>

Yes, for ECL, each .fas is a shared library and the memory save
I mentioned does not apply. But since it is shared library,
it has the PE/ELF overhead. For comparison, ABELGRP.fas (ECL)
is 117897 bytes while ABELGRP.fasl (SBCL) is 1730 bytes, 68x.
The whole algebra/ (excluding daase) is 275M vs 43M, 6.4x.

>
> This is question of balace between bandwidth and latency.
> And possibly question of loading strategy. IIUC web
> version currently uses simple strategy of downloading a domain
> when FriCAS wants to load it. But we can predict with
> rather high probablity that after loading one domain some
> other will be loaded too. So we could initiate downloading
> much earlier.
>
> In fact, in web version it probably would make sense to exclude
> Spad compiler and some other pieces to reduce size of main
> file.
>
> Maybe you have better data, but when I tried web version it
> took a lot of time to get to the first prompt, which should be
> just loading a single file.
>

Did you use
https://wangyenshu.github.io/fricas-wasm/ (individual file)
or
https://oldk1331.github.io/fricas-wasm/ (algebra/ all in one) ?

Benchmark on my side:
1. first time (no browser caching):
wangyenshu: 6s to see first prompt, 60s to compute integrate(sin(x),x)
oldk1331: 15s to see first prompt, 8s to compute integrate(sin(x),x)

2. second time (with browser caching):
wangyenshu: 5s to see first prompt, 16s to compute integrate(sin(x),x)
oldk1331: 11s to see first prompt, 8s to compute integrate(sin(x),x)

- Qian

[Matthias Koeppe]

For what it's worth, I'll mention that the number of shared libraries
(.fasl) shipped by FriCAS is extraordinary and happens to cause a
bottleneck when I build the Python package passagemath-fricas for
distribution on PyPI.
https://github.com/matthew-brett/delocate/pull/256

Matthias

> --
> 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 fricas-devel...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/19969da6-f538-4172-bde2-d981ddb2d5e9%40gmail.com.



--
Matthias Koeppe -- http://www.math.ucdavis.edu/~mkoeppe

[Waldek Hebisch]

On Sun, Jul 26, 2026 at 01:06:42PM +0800, Qian Yun wrote:
> On 7/26/26 7:57 AM, Waldek Hebisch wrote:
> >>
> >> Just thought of another benefit:
> >>
> >> If we have a single binary, then it will have a larger ".text"
> >> section, will cost more memory than load-on-demand version,
> >> but when running multiple FRICASsys processes in parallel,
> >> that could save memory because ".text" section will be shared,
> >> but '(load "xxx.fasl")' will consume heap memory and will not be
> >> shared.
> >
> > There will be some saving. But ECL .fas is just a shared library
> > and code in shared libraries is shared between processes. We
> > will probably save a bit on relocatations. But note that ECL
> > creates at runtime many things that are logically constant
> > (say a big immutable list). So there will be extra runtime
> > and extra memory use from files which are unused but included
> > in the executable.
> >
>
> Yes, for ECL, each .fas is a shared library and the memory save
> I mentioned does not apply. But since it is shared library,
> it has the PE/ELF overhead. For comparison, ABELGRP.fas (ECL)
> is 117897 bytes while ABELGRP.fasl (SBCL) is 1730 bytes, 68x.
> The whole algebra/ (excluding daase) is 275M vs 43M, 6.4x.

On Linux, I get ABELGRP.fas of about 37k. After striping I
get 14k. Size indicate that actual code is about 4k. That
seem to indicate that about half of size overhead is due
to debug info.

--
Waldek Hebisch