Consider a stack based version of scratch allocator for performant paths

XMLWordPrintableJSON

    • Type: Improvement
    • Resolution: Won't Do
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Performance
    • StorEng - Refinement Pipeline
    • None

      This ticket includes a proof of concept for a replacement for certain scratch allocations. These allocations would be initially backed by stack memory, so would be fast for allocation and free.

      Part of the reason for this would be to identify potential places where WT could be sped up. For example, we know that bounded cursors would like to be more performant. They do use scratch allocation, so maybe this would help?

      The second reason is that it might offer more opportunities or "change the way we program" if we knew that scratch allocation was very cheap in the typical case.

            Assignee:
            [DO NOT USE] Backlog - Storage Engines Team
            Reporter:
            Donald Anderson
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: