Speeds up module.add_debug_info and add_metadata by 2x

[bslatkin]

• Only generates the key for module._metadatacache a single time instead of twice on cache miss
• Avoids extra assignments in NameScope._basenamemap when there are name conflicts
• Caches computed hashes for MDValue and DIValue instances, while ensuring they'll still pickle
• Adds a test to measure performance of this path so regressions will be easy to spot
• Adds a test to make sure pickling behavior continues to work

In my own compiler's codebase, this change reduces the time it takes for my debug info regression test to complete from 180 seconds down to 20 seconds. The more nesting of metadata there is, the larger the effect.

[bslatkin]

Looks like I need to run flake8 and address some style issues. Will do that shortly.

[gmarkall]

Thanks for the PR! I'm curious about

In my own compiler's codebase, ...

Is there any public info about your compiler?

[bslatkin]

It's not public yet! Hopefully early next year I'll publish it for people to see. There are a couple of sneak peeks here:

https://twitter.com/haxor/status/1580959518984241158 https://twitter.com/haxor/status/1582878447134572544

I will also share the private project with you, Graham, so you can take a look for context.

The part that this PR specifically improves is how I assign builder.debug_metadata to a new value on nearly every token in the source file during code generation (see the file src/code_generator.py in the private project). Doing this provides excellent debug information when using tools like lldb, but it slows down deduplicating DIValues.

Thank you for looking and the attention on this PR!

[bslatkin]

Is there anything else you need from me on this PR? Just making sure. Thank you for the reviews!

[gmarkall]

Thanks for checking in - it's taking me a little while to review as I'm unfamiliar with most of the parts that are changed in this PR - apologies for the delay. I do have some review notes drafted but I'd like to finish the review before I post them.

[bslatkin]

Hi @gmarkall! My apologies for the delay. This is great feedback. I'll start working through it and update the PR once I've addressed everything. Thank you

[esc]

@bslatkin Hi! and thank you for your initial work on this. I am the release manager for 0.41.x and am checking on the status of this PR. I see that it has been in progress for quite some time. 0.41.x is now scheduled to be tagged during the week 7th August 2023, which is in 4 weeks time. What do you think, will this PR make it by then?

[bslatkin]

Thank you for the encouragement! I'm behind where I wanted to be on this, obviously :) I'll give it a try to turn it around before then. But I'm not sure how much additional review it might take, especially during the summer time. So perhaps I should aim for the release after that?

[esc]

Thank you for the encouragement! I'm behind where I wanted to be on this, obviously :) I'll give it a try to turn it around before then. But I'm not sure how much additional review it might take, especially during the summer time. So perhaps I should aim for the release after that?

It's up to you, just let me know what you prefer. Reviewers are the most scarce resource in the Numba ecosystem so I share your gut feeling that perhaps the 0.42 release is a more realistic goal.

Here is the Gnatt chart for the next few months, which shows the approximate tag dates for Numba 0.59 and 0.60 -- these will coincide with llvmlite releases, as the two libraries are released in lockstep:

https://github.com/numba/numba/issues/8971

Effectively, the next releases will be in the Nov 2023 (0.42.x) and Feb 2024 (0.43.x) time-frame.