Skip to content

#766 Separate GenericGeometries and the SmallObjectPool

Metadata

Property Value
Reported by Oliver Sander (oliver.sander@tu-dresden.de)
Reported at Apr 5, 2010 07:55
Type Feature Request
Version 1.2
Operating System Unspecified / All
Last edited by Oliver Sander (oliver.sander@tu-dresden.de)
Last edited at Jan 30, 2011 17:08
Closed by Oliver Sander (oliver.sander@tu-dresden.de)
Closed at Jan 30, 2011 17:08
Closed in version Unknown
Resolution Fixed
Comment

Description

The generic geometries override the 'new' operator of some of its constituent classes (e.g. VirtualMapping). This is done by inheriting from SmallObject (in dune/common/smallobject.hh), which then does memory handling through a singleton SmallObjectPool object.

This has a number of disadvantages:

  • The SmallObjectPool is not thread-safe. This in itself is not a problem, but you cannot use anything else.
  • It is doubtful that pool allocation is faster than stack allocation in the common case of having only a very small number of GenericGeometries (e.g. in UGGrid)
  • SmallObjectPool does the same as PoolAllocator, but the latter is standard-conforming.

The important point is really the first one.

I see two ways to solve this problem: a) Make the allocator type a parameter. People that need thread-safety can then insert an appropriate allocator b) Make everything stack-based. People that need custom allocators can then use their favorite allocators to get memory and store the entire generic geometries there.

Opinions?