Optimisation of object management 
Author Message
 Optimisation of object management

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'Hres cedex
FRANCE

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



Thu, 25 Apr 2002 03:00:00 GMT  
 Optimisation of object management

Quote:
> 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?

Quote:
>     € slow the acces to their contents;

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

Quote:
>     € slow the creation of such object;

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

Quote:
>     € 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



Thu, 25 Apr 2002 03:00:00 GMT  
 Optimisation of object management

Quote:
>     € 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

Quote:
>     € 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



Thu, 25 Apr 2002 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. OOPSLA97 paper posted: Fitting the Workflow Management Facility into the Object Management Architecture

2. New Book on Object Data Management

3. CFP-OOPSLA 98 WOrkshop on Implementation and Application of Object Oriented Workflow Management Systems

4. Deadline extension-CFP-OOPSLA 98 Workshop on Implementation and Application of Object Oriented Workflow Management Systems

5. Smalltalk, Object Database, AND Committed Management?

6. Memory Management and object finalisation

7. FAQ?: Object Management Group (OMG)

8. Object lifetime management

9. memory management and object finalization in Ruby

10. Object/Memory Management

11. Ruby objects and memory management.

12. Objects database management?

 

 
Powered by phpBB® Forum Software