[issue42525] Optimize class/module level annotation

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42525] Optimize class/module level annotation

[Yurii Karabas]

Yurii Karabas <1998uri...@gmail.com> added the comment:

After several attempts to optimize class/module annotations, I didn't find a 
solution that won't break existing code and can cover all existing edge cases.

The root cause was mentioned by Inada, the problem that `__annotations__` is 
exposed to locals and can be dynamically modified and that can't be predicted 
at compilation time.

Sorry about this issue, when I was creating this issue, I didn't realize the 
whole problem state.

We can close this issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42525] Optimize class/module level annotation

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
nosy: +pablogsal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42525] Optimize class/module level annotation

[Batuhan Taskaya]

Batuhan Taskaya  added the comment:

> For instance, we have such code:

But what about this, what would the bytecode will look like in this case (where 
the annotations don't exactly follow each other?)

a: int
T = TypeVar('T')
b: T
b1: Gen[T]
X = TypeVar('X')
c: X
d: str

Do you propose to build 2/3 different dicts and apply them one by one to allow 
calls to access that frame and recover the annotations?

> I will look more like micro-optimization, I can implement this feature and 
> run benchmarks to check performance boost.

What kind of optimization do you target? It would be really cool if you could 
get us some numbers with a draft patch (like comparing to test the import time 
of a module heavy with annotations, or even maybe some real-world examples. 
Here is a list of heavily-typed projects: 
https://github.com/hauntsaninja/mypy_primer/blob/2d14b20fa782896cc3d6ad2548a70c024b0f4e8a/mypy_primer.py#L900

Would love to see an import time comparison, or something similiar.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42525] Optimize class/module level annotation

[Yurii Karabas]

Yurii Karabas <1998uri...@gmail.com> added the comment:

As all annotations are known at compilation time we can optimize annotations 
creating.

For instance, we have such code:
```
a: int
b: int
```

With the current implementation, we will have such bytecode:
```
  1   0 SETUP_ANNOTATIONS
  2 LOAD_CONST   0 ('int')
  4 LOAD_NAME0 (__annotations__)
  6 LOAD_CONST   1 ('a')
  8 STORE_SUBSCR

  2  10 LOAD_CONST   0 ('int')
 12 LOAD_NAME0 (__annotations__)
 14 LOAD_CONST   2 ('b')
 16 STORE_SUBSCR
 18 LOAD_CONST   3 (None)
 20 RETURN_VALUE
```

I would suggest using `BUILD_CONST_KEY_MAP` and bytecode will look like this:
```
 2   0 LOAD_CONST   0 ('int')
 3   2 LOAD_CONST   0 ('int')
 1   4 LOAD_CONST   1 (('a', 'b'))
 6 BUILD_CONST_KEY_MAP  2
 8 SETUP_ANNOTATIONS
 10 LOAD_CONST  2 (None)
 12 RETURN_VALUE
```

So `SETUP_ANNOTATIONS` bytecode will accept a dictionary with annotations of a 
current module/class.

I will look more like micro-optimization, I can implement this feature and run 
benchmarks to check performance boost.

I believe this optimization won't require a lot to change.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42525] Optimize class/module level annotation

[Inada Naoki]

Inada Naoki  added the comment:

I agree with Batuhan.

Although bytecode for class annotations seems inefficient, it is difficult to 
optimize without breaking backward compatibility.
You can write arbitrary code in class/module block which dynamically manipulate 
__annotations__.

```
class Foo:
__annotations__["spam"] = "list"
ham: tuple
```

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42525] Optimize class/module level annotation

[Batuhan Taskaya]

Batuhan Taskaya  added the comment:

Would it require a substantial amount of changes? If so, I don't think this is 
a critical optimization since nearly-all of class definitions happens on the 
module level and evaluated on the import time only once.

--
nosy: +BTaskaya

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42525] Optimize class/module level annotation

[Yurii Karabas]

New submission from Yurii Karabas <1998uri...@gmail.com>:

This issue is inspired by https://bugs.python.org/issue42202

We can do smth similar for class/module level annotations.

Inada Naoki what do you think regarding that?

--
components: Interpreter Core
messages: 382263
nosy: methane, uriyyo
priority: normal
severity: normal
status: open
title: Optimize class/module level annotation
type: resource usage
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com