From: John Prevost <prevost@maya.com>
To: caml-list@inria.fr
Subject: Strange hugeness of .o, .cmo, and .cmi files
Date: 31 Mar 1999 01:19:50 -0500 [thread overview]
Message-ID: <ya2soami3jt.fsf@zarya.maya.com> (raw)
I've been working on a curses library written entirely in O'Caml, and
recently copied my sources over a slow ppp link to my machine at home.
Quite by chance, I also got a copy of the binaries, and noticed the
sizes of the .cmo and .o files for one module in particular.
This module is not terribly complex (at least from my understanding),
but it is rather large in another sense. I was wondering if anybody
could explain what's happening internally and how I could be more
efficient.
type entry = { term_names : string;
string_table : string;
booleans : bool array;
numbers : int array;
strings : int array }
type terminfo = {
auto_left_margin : bool;
auto_right_margin : bool;
[...461 lines similar, with some : int option and some : string options...]
}
[...small amount of code for reading terminfo files into entries...]
let process_entry e =
let get_bool = get_bool e in
let get_number = get_number e in
let get_string = get_string e in
{ auto_left_margin = get_bool 0;
auto_right_margin = get_bool 1;
[... another 461 lines ...]
}
[...a few more little routines...]
Obviously, there are a lot of fields in the record type, and I assume that this is where the blowup is happening, but I'm not at all sure where.
Another module, with apparently comparable amounts of code, maybe a
bit more complex is tparm.ml. Here's a comparison:
-rw-r--r-- 1 prevost users 721 Mar 31 01:07 tparm.cmi
-rw-r--r-- 1 prevost users 6400 Mar 31 01:00 tparm.cmo
-rw-r--r-- 1 prevost users 398 Mar 31 01:07 tparm.cmx
-rw-r--r-- 1 prevost users 15784 Mar 31 01:07 tparm.o
-rw-r--r-- 1 prevost users 59432 Mar 31 01:17 terminfo.cmi
-rw-r--r-- 1 prevost users 11396 Mar 31 01:00 terminfo.cmo
-rw-r--r-- 1 prevost users 1009 Mar 31 01:07 terminfo.cmx
-rw-r--r-- 1 prevost users 259076 Mar 31 01:07 terminfo.o
(compiling with -compact or without produces the same object size)
A bigger .cmi file was expected from the huge record, and I can deal
with, since it isn't used in every executable linked against it.
I'd expected a bigger object, but not 20x as big!
So, is there anything I can do to get around this, preferably without
needing to use -compact? Would a different way of accessing fields be
better? What if I went back to what I had before I decided a record
would be a good idea, which was using get_string entry some_field for
access? (for example:
let auto_left_margin e = get_bool e 1
or
let auto_left_margin = get_bool 1
with a different formulation of get_bool.)
Since everything else uses the terminfo module, and since it gets
linked into the programs whole-hog, I'd very much like to cut down on
the space use.
Thanks,
John
next reply other threads:[~1999-03-31 7:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-03-31 6:19 John Prevost [this message]
1999-03-31 15:59 ` Xavier Leroy
1999-03-31 21:36 ` John Prevost
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ya2soami3jt.fsf@zarya.maya.com \
--to=prevost@maya.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox