Opened 19 years ago
Closed 19 years ago
#3235 closed enhancement (duplicate)
[patch] resolve_variable performance issue raising VariableDoesNotExist
| Reported by: | Owned by: | Adrian Holovaty | |
|---|---|---|---|
| Component: | Template system | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | kmtracey@… | Triage Stage: | Ready for checkin |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
This has come up a couple of times on django-users: the raising of VariableDoesNotExist in resolve_variable can potentially cause a big performance hit since it may result in the entire template context being stuffed into a string. See:
and
http://groups.google.com/group/django-users/browse_thread/thread/82df8bb71571fdbf/35089038df9c1976
I'll attach a patch with (what I think is) Russ Magee's suggested fix of simply including the type of object being searched instead of a full repr of it.
Attachments (1)
Change History (5)
by , 19 years ago
| Attachment: | __init__.py.diff added |
|---|
comment:1 by , 19 years ago
| Summary: | resolve_variable performance issue raising VariableDoesNotExist → [patch] resolve_variable performance issue raising VariableDoesNotExist |
|---|
comment:2 by , 19 years ago
| Cc: | added |
|---|
comment:3 by , 19 years ago
| Triage Stage: | Unreviewed → Ready for checkin |
|---|
comment:4 by , 19 years ago
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
#3441 fix addressed this problem; full message still available if it's ever requested but up-front creation cost is gone.