[clean-list] Linking is slow with Object IO 2.0

Martin Wierich martinw@cs.kun.nl
Mon, 16 Oct 2000 12:24:10 +0200


Hi Igor,

Igor Mikheyenkov wrote:
> Hello,
> 
> I've tried compiling IO 0.8 examples and then IO 2.0 ones. It took
> sufficiently more time to link the latter.

You must have recognized that the generated executables of the Object I/O
library are much bigger than their 0.8 I/O library counterparts. Clean has an
optimizing linker (not on the unixes): Imagine a directed graph whose nodes are
the names of all functions that are defined in an implementation module that is
linked. Iff function f calls g then there is an arrow from f to g. The linker
will discard all functions that are not reachable from the "Start" node.

The reason for the long link times is that with the Object I/O library many
functions are reachable in this graph that will never be called at runtime (this
of course depends on the application program that uses the Object I/O library).
Let me give an example: in module StdControlDef you will find the following
constructor for specifying your application's tooltips:


:: ControlAttribute st =
    ...
    | ControlTip String
    ...

(A tooltip is a small text that pops up if you have your mouse pointer long
enough on (say) a button). In the Object I/O library there is some internal code
that looks up this attribute in a list of attributes in a control specification
and will call the right OS routines and do some administration. This internal
code will always be linked if you have a control in your application
_regardless_ whether your application actually uses the "ControlTip"
constructor.

So the problem is: with every new feature that is added to the Object I/O
library the executables will get bigger and bigger, regardless whether this
feature is used.

A solution to this problem could be the following: to specify such attributes
(or other GUI objects) _functions_ could be used instead of data constructors.
These functions will be the only functions that contain all the internal code
that is needed for administration. So:

  ControlTip :: String -> ControlAttribute st

with the ControlAttribute type (abstractly) defined as for example

  ControlAttribute st :== (*IOSt st -> *IOSt st)

The function that is returned by this ControlTip application will install all
code that is needed for OS communication in the I/O state (IOSt). In this way
this code will only be linked if the ControlTip function really appears in the
application program that uses the Object I/O library.

Possibly the Object I/O library is ported to Haskell. It would be just now the
right moment for the Haskell community to do some redesigning (_before_ doing
the port). Maybe they consider the above idea? Any Haskellers reading this?

bye
  Martin Wierich

P.S.: The idea to make a dynamically linked library from the Object I/O library
has been considered, but I don't know it's place on the priority list.