[mypyc] feat: __mypyc_empty_tuple__ constant
#19654
Conversation
|
In 3.13 and later, we could use |
BobTheBuidler
force-pushed
the
empty-tuple-constant
branch
2 times, most recently
from
02cd112 to
fecc89c
Compare
mypyc/lib-rt/init.c
Outdated
| PyErr_SetString(PyExc_RuntimeError, "Failed to initialize __mypyc_empty_tuple__"); | ||
| return; | ||
| } | ||
| Py_INCREF(__mypyc_empty_tuple__); |
There was a problem hiding this comment.
No need to do an incref, since PyTuple_New returns a new reference that gets implicitly transferred to __mypyc_empty_tuple__.
|
Thanks for your feedbacks, I've updated the PR accordingly. |
| size: Value = Integer(len(items), c_pyssize_t_rprimitive) | ||
| return self.call_c(new_tuple_op, [size] + items, line) | ||
| else: | ||
| return self.call_c(load_empty_tuple_constant_op, [], line) |
There was a problem hiding this comment.
Also use the new primitive in new_tuple_with_length below if length == 0.
There was a problem hiding this comment.
I'm not sure how to implement this logic at compile time because in this location, length is a Value not a known integer
we could do a boolean op to check, but then we're just recreating what already exists in PyTuple_New and making our IR longer to do it
There was a problem hiding this comment.
You are correct, please disregard my above comment.
The new function could be used in mypyc/codegen/emit.py on this line when generating C for a box operation: self.emit_line(f"{declaration}{dest} = PyTuple_New({len(typ.types)});"). If length is zero, we could use the new primitive?
There was a problem hiding this comment.
looks correct. We can also skip the subsequent NULL check. I've implemented this and the tests are running, I may need to update the IR test definitons.
I realized that any time a user has a kwarg-only call expression like
fn(abc=123, ...)in their compiled code, andfuncis not a native function, a new empty tuple is created every timeThis is not really necessary, we can just hold the same empty tuple in memory as a constant and pass it around. It's immutable, and that's already what we're already doing, since
tuple() is tuple()but our current method involves more steps.This should slightly improve the speed of kwarg-only python func calling.