Some of you may have seen the brief interchange between Kazu and myself
regarding ResourceT in WAI. Let me give a very brief synopsis of the
situation:
- In order to allow WAI applications to acquire scarce resources like
file handles in an exception-safe way, WAI actions all live in a `ResourceT
IO` monad, instead of just `IO`.
- Kazu has mentioned to me in the past that, based on his profiling,
monadic bind for ResourceT may currently be a bottleneck in WAI.
- I made an experimental change to WAI so that, instead of actions
living in `ResourceT IO`, the WAI Request value contains a ResourceT
InternalState value, which can be used to accomplish the exact same thing
as living in ResourceT (see [1]).
- Kazu checked out the performance difference of this new branch, and it
allows for some better optimizations.
If this was purely a performance optimization, I would probably just
optimize Warp and not bother changing WAI. However, I think that this
change makes WAI itself better as well, and therefore am in favor of making
this as a breaking change, releasing it as WAI 2.0[2]. Firstly, are there
any objections to this move?
So as long as we're making a breaking change, the question arises: what
other changes should we be making to WAI? I know Kazu had mentioned adding
fields to avoid the need for lookups, can you clarify that request a bit?
Here are some other changes I can think of:
- Remove the deprecated isSecure field from the Request data type.
- Remove the misleading fields serverName and serverPort fields as well.
- Possibly: hide the Request constructor so that new fields can be added
without breaking backwards compatibility.
If anyone else has some ideas, please bring them up.
[1]
http://haddocks.fpcomplete.com/fp/7.4.2/20130704-120/resourcet/Control-Mona…
[2] For the Yesod community: the change is minor enough that Yesod 1.2 can
have some conditional compilation to support both the current WAI 1.4 and
WAI 2.0, so this shouldn't affect most Yesod users at all.
Hi all,
To demonstrate the bottlenecks of GHC, I have released "witty", a
simple network server. If you specify command line options, "witty"
uses ideas to overcome the bottlenecks. I hope we can use "witty" to
convince ourselves of the problems and discuss how to fix them.
You can install "witty" by
% cabal update; cabal install witty
For more information, please read:
https://github.com/kazu-yamamoto/witty/blob/master/README.md
--Kazu
