From: Xavier Dousson
Subject: Optimisation of object management
Date: 
Message-ID: <804deb$fts$1@zak.ujf-grenoble.fr>
Hello,
my problem is the following:

I have to made symbolic computing on different objects and I need to do this the
faster I can. There are different types of object and we can suppose for example
I have only two types A and B.

An element of type A is in fact a combination of elements of type B, like for
example (B1 and B2 are two elements of type B,  A1 is an element of type A) :

    A1= 2.B1 + 3.b2

We have to add different objetcs A1, A2, ..., An of type A and so to extract the
elements of type B of an object of type A.

At the moment, I am using lists and keywords:

    An object of type A is a list        (:a something)
    and an object of type B is a list    (:b something).

So the element A1 is represented by the list      (:a (2 . (:b B1))
                                                      (3 . (:b B2)))

And the program works with it by using 'car', 'cdr', etc.

The problem is that the objects A1, B1 and B2 are not really typed.
Is there any way to have typed objects A and B which do not:

    � slow the acces to their contents;
    � slow the creation of such object;
    � take more place in memory.

If someone have an idea to improve one of the third condition whithout typing
object, I am interesting too.

Xavier Dousson
---
Institut Fourier, BP 74
38402 Saint Martin d'H�res cedex
FRANCE

Look at the Kenzo program, a program in Algebraic Topology:
     www-fourier.ujf-grenoble.fr/~sergeraert/Kenzo

From: Rainer Joswig
Subject: Re: Optimisation of object management
Date: 
Message-ID: <rainer.joswig-0711992141170001@194.163.195.67>
In article <············@zak.ujf-grenoble.fr>, "Xavier Dousson" <··············@ujf-grenoble.fr> wrote:

> The problem is that the objects A1, B1 and B2 are not really typed.
> Is there any way to have typed objects A and B which do not:
> 

How about using structures? 

>     � slow the acces to their contents;

Given sufficiently high
optimization, you should get inlined
accessors to structures.

>     � slow the creation of such object;

Maybe you want to deal with pools of preallocated
objects/structures (called resources).

>     � take more place in memory.

Symbols can be space expensive (package, name, value,
function, property list) - when you need lots of them.

-- 
Rainer Joswig, ISION Internet AG, Harburger Schlossstrasse 1, 
21079 Hamburg, Germany, Tel: +49 40 77175 226
Email: ·············@ision.de , WWW: http://www.ision.de/
From: Tim Bradshaw
Subject: Re: Optimisation of object management
Date: 
Message-ID: <ey3hfixnawu.fsf@lostwithiel.tfeb.org>
>     � slow the acces to their contents;
>     � slow the creation of such object;

I should think that structures are pretty quick for both of these in
any reasonable implementation

>     � take more place in memory.

However, they are likely to be larger as well, because they'll need
type bits that will often be encoded in the pointer for conses.

Note though that if you are using a lot of symbols, then structures
will often be *smaller*, because symbols are really big.

--tim