Description
Over the years we've had a number of suggestions (collected below) for improving DRF performance. These have often stalled for lack of a suitable benchmarking measure.
Progress on these issues requires:
- A benchmarking project that we can keep up to date and run repeatedly against proposed changes (and the base branch for comparison).
With that in place we could sensibly assess changes, and either accept or reject them, rather than leaving them to rot indefinitely in the issue tracker.
Design Note: Performance isn't a primary goal of Django REST Framework. Rather we're into clarity and ease-of-use. (Other speed-ups, e.g. caching at another level, are often the way to go anyway.) Clean changes that are performance wins are still wins: they're worth having.
Related Tickets:
List of tickets suggesting improvements. Not necessarily complete (— Do add relevant issues!). Blocked by lack of benchmarking. Worth revisiting once we have a solution in place.
- Document explicit speedup approaches. #1994 Document explicit speedup approaches.
- Test template rendering performance for HTMLRenderer. #2093 Test template rendering performance for HTMLRenderer.
- Cache/pickle performance for Serializer data (many=True) #2454 Cache/pickle performance for Serializer data (many=True)
- ModelSerializer caching. #2504 ModelSerializer caching.
Calling reverse is very expensive #3007 Calling reverse is very expensive(Fixed in Django)- Serializer - one level copy instead of deepcopy #4587 Serializer - one level copy instead of deepcopy. (Does it handle nesting?)