Opened 4 years ago
Last modified 3 months ago
#32568 assigned Cleanup/optimization
Prefer SafeString to mark_safe where possible — at Initial Version
| Reported by: | Tim McCurrach | Owned by: | nobody |
|---|---|---|---|
| Component: | Template system | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
mark_safe takes roughly twice as long as simply creating a SafeString - using pyperf:
mark_safe: Mean +- std dev: 296 ns +- 12 ns SafeString: Mean +- std dev: 158 ns +- 7 ns
There are many places in the django codebase where we know the thing we are marking as safe to be a normal string. In such cases it makes sense to use SafeString instead of mark_safe.
To play devils advocate, you could definitely argue that this is an unnecessary micro-optimisation. Following a brief search for mark_safe, there are some situations where we have something like mark_safe(X) and where evaluating X will take sufficiently long that any savings made marking the string as safe would be rendered insignificant.
Having said that, there are other places where we end up calling mark_safe a very large number of times. In such situations a small saving in time will add up to a larger saving. There are also places where we even have mark_safe("some string literal").
Furthermore, since this change is literally just replacing one word with an equally clear word, it would have no effect on complexity or readability, and so for a slight performance boost, why not?