#36520: Performance Regression in parse_header_params
---------------------------------+------------------------------------
     Reporter:  David Smith      |                    Owner:  (none)
         Type:  Bug              |                   Status:  new
    Component:  HTTP handling    |                  Version:  dev
     Severity:  Release blocker  |               Resolution:
     Keywords:                   |             Triage Stage:  Accepted
    Has patch:  0                |      Needs documentation:  0
  Needs tests:  0                |  Patch needs improvement:  0
Easy pickings:  0                |                    UI/UX:  0
---------------------------------+------------------------------------
Comment (by Natalia Bidart):

 Replying to [comment:17 Jake Howard]:
 > The `requests` implementation was the most interesting to me, being so
 much faster. After plugging it in to Django however, it seems it's not
 quite as robust - many of the test cases fail and produce very unexpected
 results. `werkzeug`'s implementation appears to be more robust to the
 weird edge cases we need to handle, but still isn't perfect.

 Thanks for checking!

 > To revert or not to revert feels difficult. On the one hand, the `cgi`
 implementation is faster almost across the board. However, it's a fair bit
 of work to maintain, and parser code like that tends to be where security
 issues get introduced. `Message().get_params` is slower (at least on the
 easy cases), but using `bytes` makes it slightly less slower than it
 currently is, is the officially recommended path forward, and could get
 improvements as time goes on (removing the need to create a new `Message`
 instance each time improves performance quite a bit). Personally, I'd vote
 for adding the short-circuit and `bytes` changes over reverting.

 I fully agree with this rationale.

 > As an aside, to integrate `requests` and `werkzeug`'s implementations
 into Django, I had to modify how multi-part form parsing worked, since it
 passed the entire header to `parse_header_parameters`, rather than just
 the value. I doubt it'll be a performance improvement, but probably
 something worth cleaning up regardless, especially if we do swap out the
 implementation. I can push up a PR if it's useful?

 Yes please, a PR with these fixes would be much appreciated. Let me know
 when it's up so I can prioritize it for reviews. Thank you for
 investigating further!
-- 
Ticket URL: <https://code.djangoproject.com/ticket/36520#comment:18>
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 django-updates+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/django-updates/01070198c7c2340d-6763592c-f7ab-4fbe-9708-8f83d7c1728d-000000%40eu-central-1.amazonses.com.

Reply via email to