# Performance of typed.List outside of jit functions

**URL:** <https://numba.discourse.group/t/performance-of-typed-list-outside-of-jit-functions/2560>\
**Category:** Community Support\
**Created:** [May 11, 2024, 6:19am UTC](https://numba.discourse.group/t/performance-of-typed-list-outside-of-jit-functions/2560 "2024-05-11T06:19:31Z")\
**Posts on this page:** 1\
**Showing post:** 12

<div class="post-metadata">

**Author:** ![DannyWeitekamp](https://yyz2.discourse-cdn.com/free1/user_avatar/numba.discourse.group/dannyweitekamp/32/144_2.png) [@DannyWeitekamp](https://numba.discourse.group/u/DannyWeitekamp)\
**Post date:** [May 12, 2024, 5:07pm UTC](https://numba.discourse.group/t/performance-of-typed-list-outside-of-jit-functions/2560/12 "2024-05-12T17:07:57Z")

</div>

Also there are perhaps a few more optimizations which might account for some of the discrepancy between my entry\_point trick (10x slower) and numpy (2x slower), which I was hoping the new AOT stuff would make easier. At the moment List()'s methods are implemented by calling into a pre-compiled C library that implements most of its functionality so it runs something like this:

Python-\>Multiple Dispatch-\>Call End-point-\>Call Opaque C-Func

The inefficiency is that there are multiple opaque function calls that aren’t currently inlined, but could be if the compilation pipeline could inline the C library by compiling it with clang and inlining the LLVM IR instead of calling out to it as an external library.

In addition to this I expect the unboxing phase does some refcount incrementing that could be skipped.

---

_[View the full topic](https://numba.discourse.group/t/performance-of-typed-list-outside-of-jit-functions/2560)._