new field for Network.HTTP.Types.Status
Hello, I'm now tuning warp. https://github.com/kazu-yamamoto/wai/tree/refactoring/warp One of bottlenecks is the code to compose HTTP header. I have already rewritten the code using direct memory copy instead of BlazeBuilder. https://github.com/kazu-yamamoto/wai/blob/refactoring/warp/Network/Wai/Handl... This code gain around 2,000 req/s on my machine. In this code, you can find two 'divMod' and one 'mod'. These is to convert numeric HTTP status code to ByteString. It appeared this conversion is slow. Note that due to a bug of GHC, five (not three) divisions are carried out. So, I redefined Network.HTTP.Types.Status to have reformatted ByteString for status code (the statusAsciiCode field): https://github.com/kazu-yamamoto/http-types/blob/status-ascii-code/Network/H... This hack gains also around 2,000 req/s. This change breaks compatibilities. I found that warp, http-conduit, wai-app-file-cgi are affected. So, my question: is this hack acceptable? If not, I will define a large array of ByteString in warp. But it seems to me that this is nonsense. --Kazu
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
So, I redefined Network.HTTP.Types.Status to have reformatted ByteString for status code (the statusAsciiCode field): https://github.com/kazu-yamamoto/http-types/blob/status-ascii-code/Network/H...
It seems like this could be solved with a lookup table. If this change is made I think it would need to make sense to hide the Status constructor and use a smart constructor or similar. - -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJQNTSQAAoJENEcKRHOUZzec0MP/i5K9V+0mFEM55Tcq3EhxZbI CzJa8w1cmcbNd1XRSRLhhBok68APFFx05F2XEDjIU9ui1WRBGzyv5K28/p5QJ4ev 58WfXBPIKVEaeHp0bcmxRmo4IMDiLasdhs55LQMMa4fqmdcwc4gEJR3BnmjNoeMQ 4JUUrKmQPW3yxJJ84k2y7uFIpSLgAypJiKGmYAyJ4+jdkjLpGqV0+aH99d1tvBAh WeJq4RP77eBjG8JMyTIsllZ5z7kBn694Hmqhepxmm4J2m3InQofhPnfTbwGvI5t6 r+VRIBbOgo0fuZrG1VqOhqqvZi3vpGWTGTi2h5oiejT2l5SYXsHWeS6lCSx5TmvC QqR0KgKHu1tbTSaJFZzFjFPwshYIwMKTgM4jXGV52x77pNhUFulFNeGgQ9YfxBpn 63hRqYjBnlywDBh/7RvHzX0oro7rthWjPPFfk7rWZi0st1f/Pvv8IjdrQiK0N/Qo kA8VIRUKdIlKLZkwf4KOe/xm8BIRyvtgxg5fWhCX+Eja2rOSrAOHF6cpoqddfCnF 1X2rC1MxNZxVxiiIN/7CDtSk592RtDZmOZAFGgdg1lpGo3F7nrp8UhxdbUthbdfi YdT/GNcnlvus3q9DQ96TRI1KYbdIXPkNI04KLUmrQVKDEX1fGReB8bO8GSDPpONf N4KU/OPTPCMYwpiFwnYv =pPTJ -----END PGP SIGNATURE-----
Hi,
So, I redefined Network.HTTP.Types.Status to have reformatted ByteString for status code (the statusAsciiCode field): https://github.com/kazu-yamamoto/http-types/blob/status-ascii-code/Network/H...
It seems like this could be solved with a lookup table. If this change is made I think it would need to make sense to hide the Status constructor and use a smart constructor or similar.
Thank you for taking time. I implemented an array some days ago: https://github.com/kazu-yamamoto/http-types/blob/status-array/Network/HTTP/T... But it appeared that this week is too busy to test it. I will come back this issue in the next week. Sorry for the delay. --Kazu
Hello, Sorry for the delay. I compared several approaches: Original (divMod): 40,280.7 req/s Hard coded literal ("200"): 43,888.6 req/s Array: 41,566.2 req/s A new field: 43,098.6 req/s This result makes sense to me. Since the new field is remarkably faster than the array. I would like to take this approach. If Aristid agree, I will send a pull request. My modification is here: https://github.com/kazu-yamamoto/http-types/commit/e8c2cf2672318e9f32ad3aafb... --Kazu
Hi,
So, I redefined Network.HTTP.Types.Status to have reformatted ByteString for status code (the statusAsciiCode field): https://github.com/kazu-yamamoto/http-types/blob/status-ascii-code/Network/H...
It seems like this could be solved with a lookup table. If this change is made I think it would need to make sense to hide the Status constructor and use a smart constructor or similar.
Thank you for taking time. I implemented an array some days ago:
https://github.com/kazu-yamamoto/http-types/blob/status-array/Network/HTTP/T...
But it appeared that this week is too busy to test it. I will come back this issue in the next week. Sorry for the delay.
--Kazu
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
participants (2)
-
Kazu Yamamoto -
Stephen Paul Weber