Vincent Trussart writes:
> "B. Craig Taverner" wrote:
>
> > Hi,
> >
> > 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).
> >
> > 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.
> >
> > Does anyone know of a good way to solve this problem? Any suggestions
> > around the issue of object creation performance are welcome.
>
> One way to handle this problem would be to create an Object pool.
> There was an article on javaworld (www.javaworld.com) a few months
> back. Basically, instead of creating new objects you request them from the
> pool. When they are not needed anymore, you put them back in the pool. This
>
> way the GC won't collect them.
> The pool must be able to "clean up" objects and so on...
Right. I've known projects that have done this and won big. Creating objects
is somewhat expensive because it's a synchronous operation, and synchronized
operations are slow in the 1.1 VM (1.2 uses a completely different and clever
trick to get the overhead of synchronization down into the noise).
Steve
