#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?