#32568: Prefer SafeString to mark_safe where possible
-------------------------------------+-------------------------------------
Reporter: Tim McCurrach | Owner: Tim
Type: | McCurrach
Cleanup/optimization | Status: assigned
Component: Uncategorized | Version: 3.1
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Tim McCurrach:
Old 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?
New 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 (not marked as safe) 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?
--
--
Ticket URL: <https://code.djangoproject.com/ticket/32568#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/071.21e25b71544c9772b29682053d41bd81%40djangoproject.com.
