id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
32568	Prefer SafeString to mark_safe where possible	Tim McCurrach	Pravin	"`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? "	Cleanup/optimization	closed	Template system	dev	Normal	fixed			Ready for checkin	1	0	0	0	0	0