Opened at 2009-08-11T05:13:33Z
Last modified at 2024-06-17T00:27:26Z
#219 new planned
implement the TypedAllocationManager backend properly
| Reported by: | Ichthyostega | Owned by: | Ichthyostega |
|---|---|---|---|
| Priority: | lesser | Milestone: | 2beta |
| Component: | lumieraSteam | Keywords: | QA performance cleanup |
| Sub Tickets: | #218, #1365 | Parent Tickets: | #126, #130, #231 |
Description
Replace the dummy (heap based) implementation. This should be a real custom allocator, built on top of the mpool.
Change history (5)
comment:1 by , at 2010-06-05T01:15:56Z
| blocking: | 126, 130 → 130, 231 |
|---|
comment:2 by , at 2010-06-05T01:16:15Z
| blocking: | 130, 231 → 126, 130, 231 |
|---|
comment:3 by , at 2024-05-13T21:45:02Z
| blockedby: | 218 → 218, 1365 |
|---|
comment:5 by , at 2025-12-25T00:00:00Z
| blockedby: | 218, 1365 |
|---|---|
| blocking: | 126, 130, 231 |
| Parent Tickets: | → 126, 130, 231 |
| Sub Tickets: | → 218, 1365 |
Migration MasterTickets ⟼ Subtickets-plugin
Note:
See TracTickets
for help on using tickets.
As part of the effort towards an allocation scheme for render nodes (#1365),
AllocationClusterwas reworked altogether and does no longer group by object types; it is now oriented towards low admin overhead and fast clean-up rather. ThusTypedAllocationManageris now on its own (and its relevance for actual remains to be seen). That being said, the general purpose heap allocator of the standard library was drastically improved over the last years. Given our modern machines, It seems more and more questionable if there is still room for a custom yet general purpose allocation scheme, as proposed at that time withmpool. It seems conceivable that some fine-tuned special case allocators are enough to reach an acceptable performance level, while most occasional allocations can be left to the default allocator.