[Django] #35236: Access Field.attname and Field.column directly

[Django]

#35236: Access Field.attname and Field.column directly
-------------------------------------+-------------------------------------
Reporter: Adam | Owner: nobody
Johnson |
Type: | Status: assigned
Cleanup/optimization |
Component: Database | Version: dev
layer (models, ORM) |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Many field references call `Field.get_attname_column()` or
`Field.get_attname()`, despite the `attname` and `column` attributes
containing the computed results (after `contribute_to_class()`). Updating
those call sites to plain attribute access eliminates some function calls,
a worthy small speedup.

From a profile of system checks on a smaller project, there were ~1k calls
for various versions of each method:

{{{
630 0.000 0.000 0.000 0.000
__init__.py:976(get_attname_column)
208 0.000 0.000 0.000 0.000
related.py:1122(get_attname_column)
431 0.000 0.000 0.000 0.000 related.py:1119(get_attname)
666 0.000 0.000 0.000 0.000 __init__.py:973(get_attname)
}}}

All of these are eliminated by moving to attribute access.
--
Ticket URL: <https://code.djangoproject.com/ticket/35236>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#35236: Access Field.attname and Field.column directly
-------------------------------------+-------------------------------------

Reporter: Adam Johnson | Owner: Adam
Type: | Johnson
Cleanup/optimization | Status: assigned
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Adam Johnson):

* has_patch: 0 => 1
* owner: nobody => Adam Johnson


Old description:

> Many field references call `Field.get_attname_column()` or
> `Field.get_attname()`, despite the `attname` and `column` attributes
> containing the computed results (after `contribute_to_class()`). Updating
> those call sites to plain attribute access eliminates some function
> calls, a worthy small speedup.
>
> From a profile of system checks on a smaller project, there were ~1k
> calls for various versions of each method:
>
> {{{
> 630 0.000 0.000 0.000 0.000
> __init__.py:976(get_attname_column)
> 208 0.000 0.000 0.000 0.000
> related.py:1122(get_attname_column)
> 431 0.000 0.000 0.000 0.000 related.py:1119(get_attname)
> 666 0.000 0.000 0.000 0.000 __init__.py:973(get_attname)
> }}}
>
> All of these are eliminated by moving to attribute access.

New description:

Many field references call `Field.get_attname_column()` or
`Field.get_attname()`, despite the `attname` and `column` attributes
containing the computed results (after `contribute_to_class()`). Updating
those call sites to plain attribute access eliminates some function calls,
a worthy small speedup.

From a profile of system checks on a smaller project, there were ~2k calls
between the versions of each method:

* 630 for `Field.get_attname_column()`
* 208 for `ForeignKey.get_attname_column()`
* 666 for `Field.get_attname()`
* 431 for `ForeignKey.get_attname()`

All of these are eliminated by moving to attribute access.

--

--
Ticket URL: <https://code.djangoproject.com/ticket/35236#comment:1>

[Django]

#35236: Access Field.attname and Field.column directly
-------------------------------------+-------------------------------------
Reporter: Adam Johnson | Owner: Adam
Type: | Johnson
Cleanup/optimization | Status: assigned
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Mariusz Felisiak):

I'm pretty sure this will break some 3rd party packages,
e.g.[https://github.com/martsberger/django-
joinfield/blob/c73bb4cfb7827126ac57c5bdf6b6a3b7e10dd54e/joinfield/joinfield.py#L60-L61
django-joinfield]. I don't think it's worth doing.
--
Ticket URL: <https://code.djangoproject.com/ticket/35236#comment:2>

[Django]

#35236: Access Field.attname and Field.column directly
-------------------------------------+-------------------------------------
Reporter: Adam Johnson | Owner: Adam
Type: | Johnson
Cleanup/optimization | Status: assigned
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Adam Johnson):

I think it has very little chance to break things. There are hundreds of
pre-existing uses of `.attname` and `.column`, the PR only updates a
handful. Also, non-deterministic `attname` would be somewhat meaningless,
as nothing would reattach the field’s descriptor with a different
attribute name.
--
Ticket URL: <https://code.djangoproject.com/ticket/35236#comment:3>

[Django]

#35236: Access Field.attname and Field.column directly
-------------------------------------+-------------------------------------
Reporter: Adam Johnson | Owner: Adam
Type: | Johnson
Cleanup/optimization | Status: assigned
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:

Keywords: | Triage Stage: Accepted

Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Mariusz Felisiak):

* stage: Unreviewed => Accepted

Comment:

I'm always preoccupied with such cleanups as more often than not they
cause regressions, but agreed, let's give it a chance.
--
Ticket URL: <https://code.djangoproject.com/ticket/35236#comment:4>

[Django]

#35236: Access Field.attname and Field.column directly
-------------------------------------+-------------------------------------
Reporter: Adam Johnson | Owner: Adam
Type: | Johnson
Cleanup/optimization | Status: assigned
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:

Keywords: | Triage Stage: Ready for
| checkin

Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Mariusz Felisiak):

* stage: Accepted => Ready for checkin

--
Ticket URL: <https://code.djangoproject.com/ticket/35236#comment:5>

[Django]

#35236: Access Field.attname and Field.column directly
-------------------------------------+-------------------------------------
Reporter: Adam Johnson | Owner: Adam
Type: | Johnson

Cleanup/optimization | Status: closed

Component: Database layer | Version: dev
(models, ORM) |

Severity: Normal | Resolution: fixed

Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Mariusz Felisiak <felisiak.mariusz@…>):

* resolution: => fixed
* status: assigned => closed

Comment:

In [changeset:"31314980be428c0ab8a6cf40cce0a0c17ead8ec6" 31314980]:
{{{#!CommitTicketReference repository=""
revision="31314980be428c0ab8a6cf40cce0a0c17ead8ec6"
Fixed #35236 -- Used Field.attname/column attributes instead of
get_attname()/get_attname_column().
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/35236#comment:6>