In article <············@early-bird.think.com> ······@think.com (Barry Margolin) writes:
--> In article <··········@info-server.bbn.com> ·····@bbn.com writes:
--> >is there a generic tree-shaker out there? I'm thinking of doing one. it
--> >can't be that difficult.
-->
--> There's no portable way to find out what functions or global variables are
--> referenced by compiled functions. How can you write a portable tree-shaker
--> without this? You could operate on source code, but then you'ld only be
--> able to look at your own code.
well, I'm using Allegro 4.2
there's a "who-calls database" created during compile/load/someplace,
which is what I expected to use to support this. it should work in
anything in the "database".
--> >in particular, I'd like to be able to limit its search to specific
--> >packages, so that it only operates on my modules.
-->
--> Do you mean that it should only shake out the parts of your modules that
--> aren't used?
yep. we're using some things that were written here, but not by anyone
still employed here (or forgotten by those who are). I'm not convinced
that ALL of those modules are really fully used.
--> >I delivered to my customer last week, and our standalone executable was
--> >20 megabytes. (yes, that's 20MB) that includes lisp, compiler, clim2,
--> >and our stuff. our stuff is 12 of the 20.
-->
--> If you only limit the tree-shaking to your modules, you'll have to leave in
--> the compiler, clim2, the interpreter, etc. These are usually the things
--> one tries to get rid of with a tree-shaker.
no, I want to dump bits of our own stuff. other stuff would be nice,
too, but not required. as I wrote, 60% of the total code is from our
source. I realize that a chunk of it is macro-expansion of CLIM stuff,
but I wonder about things anyway.
but having gotten no positive response, I presume there isn't one around
(other than Lucid's built-in whatever it is)
-- clint
In article <··········@info-server.bbn.com> ·····@labs-n.bbn.com writes:
...
well, I'm using Allegro 4.2
there's a "who-calls database" created during compile/load/someplace,
which is what I expected to use to support this. it should work in
anything in the "database".
It isn't really portable, but if you hunt around you can often find a way
to identify the functions called by another function. The ILISP emacs
interface my provide a who calls for several lisps. In Lucid, for example,
you can find the functions called by a function by inspecting that
function.
You should be able to do some of the following things when you build a
delivery world (everything is compiled). Usually a list will provide some
of these.
o Drop arglist info.
o Drop documentation
o Drop meta dot info.
o Drop macros
o Drop unwanted functions (computed before hand, somehow)
You can do this by rewriting the runtime functions that install functions
to do all the above things. This might not shrink things as much as you
like, but its worth a try.
One thing i've never gotten around to try is to work things so that all
string constants (or at least error strings) are written to a file and only
loaded as needed. In think Unix had a facility to do this for C.
There are probably plenty of accessor methods that you don't need unless
you've been very careful to define your classes.
It's a start.
k
--
Ken Anderson
Internet: ·········@bbn.com
BBN ST Work Phone: 617-873-3160
10 Moulton St. Home Phone: 617-643-0157
Mail Stop 6/4a FAX: 617-873-2794
Cambridge MA 02138
USA