Thanks @guilhermeleobas !

I'm not familiar with IR Builder stuff, your comments are valuable for me! Will address them one-by-one.

Off topic: I often saw

CondaHTTPError: HTTP 524 CONNECTION FAILED for url <[https://conda.anaconda.org/numba/label/dev/linux-64/llvmlite-0.43.0dev0-py310he1b5a44_12.tar.bz2>](https://conda.anaconda.org/numba/label/dev/linux-64/llvmlite-0.43.0dev0-py310he1b5a44_12.tar.bz2%3E)

this network error in CI recently, but normal users don't have permissions to rerun this single job.

Perhaps someone can add retries=2 in CI config if detecting this kind of HTTP Error?

I think this is ready for review.
All failing jobs are Before install or Build error related to HTTP errors and llvmlite.
All other jobs are passed.

Will add a release note soon and post some perf test and result.

Here is a mini-benchmark:

import os
import random
import time

from numba import njit, typed, types

N = 100000

@njit
def koo():
    keys = [i for i in range(N)]
    values = [random.randint(1, 100) for _ in range(N)]
    d = dict(zip(keys, values))

    for _ in range(N):
        d[random.randint(N+1, N+N)] = random.randint(1, 100)

    tot = 0
    for _ in range(N):
        tot += d[random.randint(0, 100)]

    # for i in range(N):
    #     del d[i]

    return tot

koo()
start = time.time()
for _ in range(100):
    koo()
print(time.time() - start)

On my machine, the ratio is 0.88

1. without this PR, its time is 0.7227180004119873
2. with this PR, its time is 0.6371762752532959

But I found a more profound inherent limitation in current numba impl: in theory, I want to give a typed-based operation dispatching for primitive types and container types (which even include 2 kinds, with meminfo, and without meminfo).

In the first thought, I want to implement this template in C, but I feel it's not easy. So in this PR, I tried to implement this template for primitive types with llvmlite IR builder. However, the actual call chain is

LLVM IR function (e.g., `koo`) 
    --> Numba C Dict Implementation (e.g., `dict_lookup`)
        --> LLVM IR function (generated by this PR, e.g., `key_equal`)

The two call-frames make the execution slower, given key_equal with primitive types is pretty fast.
In fact, if I put a specialized key_equal in C Dict implementation, it can be faster.

Any idea about how to implement this template stuff for primitive types in C side and can easily interact with Numba-generated LLVM modules/functions?

Hi @dlee992, I can review this by the end of the week. Don't worry about the CI failures that are not directly related to your PR.

@guilhermeleobas, cool! All checks have passed this time.

A concern: as I mentioned in a previous comment a more profound inherent limitation, do you think PIXIE can overcome this limitation, given it would emit&inject LLVM IR of C/C++ code into numba generated LLVM module, which can bring more optimisation chance?

Updates after checking the demo notebook in PIXIE repo: I feel PIXIE also can't solve this issue very well, but not pretty sure.

not sure what changes, but the result of the mini-benchmark becomes 0.7 vs 1.4, speed up is 2x.

Can we put this into 0.60rc?

gentle ping @guilhermeleobas , can review this again.

BTW, I noticed related key_equal, key_copy and val_copy will appear in the LLVM IR module many times. Not sure if it's expected.

Looks like we can't put this into 0.60. Then perhaps put it into 0.61rc?

I believe this PR has been reviewed from you in a very quick speed! Compared to my other PRs. : )

I believe this PR has been reviewed from you in a very quick speed! Compared to my other PRs. : )

If you need review in any other PR, feel free to ping me.

Since this touches part of the C code, it would be good if anyone else could review. Meanwhile, do you have the number of how fast these functions are? If so, could you also share the code you're using to benchmark these functions?

Here is a mini-benchmark (I guess you forgot this?) #9520 (comment)

Here is a mini-benchmark (I guess you forgot this?) #9520 (comment)

Oops, my bad. I'll try locally.

edit: Here are the numbers I get locally with your benchmark:

main: ~0.75
your branch: ~0.61