On Mon, 28 Sep 1998 21:34:24 +0200 (CEST), B. Craig Taverner wrote:

>I'm dealing with a performance issue in java where it appears that
>performance is noticably affected by the fact that many (thousands) of
>relatively small objects need to be created very quickly (multiple small
>memory allocations). From my C/C++ background I would have considered
>solving this problem by allocating the objects in reasonable sized blocks
>of objects (single alloc for many objects to minimize system calls).
>Individual objects could still be accessed (perhaps
>calloc/sizeof/typecast) and could then continue to be referenced in the
>normal way (hashtables, vectors, trees, etc). 

This is really part of what a "better" JVM would do for you.  In
most cases, it really should be the domain of the JVM to solve some
of these optimization issues.

>However, I do not see any obvious way to achieve this in java.  You cannot
>simply allocate a chunk of memory (you also cannot know the object size,
>or typecaste the memory to the object type).  If I allocate an array of
>objects, I'm simply allocating an array object that contains references to
>the correct object type, but does not actually contain those objects, and
>they still need to be created.

Well, there is no direct way to do this.  However, some things that can
be done is to have static methods be used to get instances of objects
and keep the constructor private.  Then the objects can make their own
tracking of usage and reuse themselves rather than always recreating
themselves.  (These are generally known as object pools)  Sun even
talked about how these can help with objects that are expensive to
create, such as threads.

>Does anyone know of a good way to solve this problem?  Any suggestions
>around the issue of object creation performance are welcome.

Well, other than doing work on a JVM to make better allocation systems
and stuff like that, the only choice is doing the pooling of objects
within your own Java code but this can complicate things and make the
code that much harder to understand and maintain.

A JVM could, for example, notice that you are reusing certain objects
and implement the pools "automatically" for you and thus provide the
benefit for all java code without adding complexity to the Java code.
(Just to the JVM, but that is ok since it is somewhat reused :-)

Michael Sinz -- Director of Research & Development, NextBus Inc.
mailto:[EMAIL PROTECTED] --------- http://www.nextbus.com
My place on the web ---> http://www.users.fast.net/~michael_sinz

Reply via email to