Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

pfalcon
Copy link
Contributor

@pfalcon pfalcon commented Nov 14, 2016

@dpgeorge , did you know that calling __call__ on instances always leads to heap alloc? The code was originally implemented in such way by me. As you can see, the patch is awful, it duplicates code in objboundmeth.c, etc.

Why mp_call_function_n_kw() wasn't originally implemented in such a way as to require a slot for self at the beginning of args, then skip it if not needed? Unless there were good reasons, let's refactor that now ;-).

@pfalcon
Copy link
Contributor Author

pfalcon commented Nov 14, 2016

This comes from #2622 (comment)

@dpgeorge
Copy link
Member

Why mp_call_function_n_kw() wasn't originally implemented in such a way as to require a slot for self at the beginning of args, then skip it if not needed? Unless there were good reasons, let's refactor that now ;-).

Please elaborate on this idea. Do you mean that mp_call_function_n_kw() should take an extra argument which is the first argument, like mp_call_function_n_kw(fun, arg0, n_args, n_kw, args). Or that the array args should contain an empty slot at args[0]? If the latter then, well, ignoring the fact that this array is const (and I think it's const for a good reason), mp_obj_instance_call won't be able to use the empty slot because the same incoming array is then passed to mp_call_function_n_kw, which requires another empty slot.

@pfalcon
Copy link
Contributor Author

pfalcon commented Nov 22, 2016

Or that the array args should contain an empty slot at args[0]?

I meant this.

mp_obj_instance_call won't be able to use the empty slot because the same incoming array is then passed to mp_call_function_n_kw, which requires another empty slot.

So, per the idea above, it's not "empty" slot, but "self" slot. There can be only 1 self argument, so it's not recursive, but static. I looked at what it would take to add it, and changes are indeed substantial. But what I somehow assumed that a lot of code paths would be affected by this issue, but looking at the code reminded that everything what's possible was already optimized, specifically expressions of the form obj.symbol(...). So, the problem (specifically, a need to semantically "explode" obj(...) into obj.prop(obj, ...)) affects only 2 cases: meth = obj.meth; ... ; meth(...) and obj(...). Expressed like that, it was easy to find a good solution - to reuse the same code paths for both cases: 037e691

tannewt added a commit to tannewt/circuitpython that referenced this pull request Feb 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants