• Show log

    Commit

  • Hash : 08b318c0
    Author : Patrick Steinhardt
    Date : 2018-03-14T10:43:00

    stdalloc: extend allocators by file and line
    
    Our desired architecture would make allocators completely pluggable,
    such that users of libgit2 can swap out memory allocators at runtime.
    While making e.g. debugging easier by not having to do a separate build,
    this feature can also help maintainers of bindings for libgit2 by tying
    the memory allocations into the other language's memory system.
    
    In order to do so, though, we first need to make our two different
    pre-existing allocators "stdalloc" and "crtdbg" have the same function
    signatures, as the "crtdbg" allocators all have an additional file and
    line argument. This is required to build correct stack traces for
    debugging memory allocations. As that feature may also be interesting to
    authors of other applications for debugging libgit2, we now simply add
    these arguments to our standard allocators.
    
    Obviously, this may come with a performance penalty. During some simple
    benchmarks no real impact could be measured though in contrast to a
    simple pluggable allocator. The following table summarizes the
    benchmarks. There were three different builds with our current standard
    allocator ("standard"), with pluggable authenticators accessed via
    function pointers ("pluggable") and for pluggable authenticators with
    file and line being added ("fileline"). Furthermore, there were three
    scenarios for 100.000.000 allocations of 100B ("small alloc"),
    100.000.000 allocations of 100KB ("medium alloc"), and 1.000.000
    allocations of 100MB. All results are best of 10 runs.
    
    |------------|-------------------|-------------------|-------------------|
    | build/test | small alloc       | medium alloc      | big alloc         |
    |------------|-------------------|-------------------|-------------------|
    | standard   | 4539779566, +0.0% | 5912927186, +0.0% | 5166935308, +0.0% |
    |------------|-------------------|-------------------|-------------------|
    | pluggable  | 4611074505, +1.5% | 5979185308, +1.1% | 5388776352, +4.2% |
    |------------|-------------------|-------------------|-------------------|
    | fileline   | 4588338192, +1.1% | 6004951910, +1.5% | 4942528135, -4.4% |
    |------------|-------------------|-------------------|-------------------|
    
    As can be seen, there is a performance overhead for pluggable
    allocators. Furthermore, it can also be seen that there is some big
    variance between runs, especially in the "big alloc" scenario. This is
    probably being caused by nondeterministic behaviour in the kernel for
    dynamic allocations. Still, it can be observed that there should be no
    real difference between the "pluggable" and "fileline" allocators.