That's great to hear Bryan. I look forward to all of your projects you just mentioned, and work from others like you said, so one day soon we can built really high-performance web servers in elegant Haskell code.
I also like Reactive (or FRP in general) as a declarative alternative to message passing, and hope it will be high-performance as well.
Cheers,
Tony
On Thu, Jan 8, 2009 at 1:07 PM, Manlio Perillo <manlio_perillo@libero.it> wrote:
Another example is the multipart parser:
-- | Read a multi-part message from a 'Handle'.
-- Fails on parse errors.
hGetMultipartBody :: String -- ^ Boundary
-> Handle
-> IO MultiPart
hGetMultipartBody b h =
do
s <- BS.hGetContents h
case parseMultipartBody b s of
Nothing -> fail "Error parsing multi-part message"
Just m -> return m
Yes, that's definitely on the scary side of things.
However, you don't have to go all the way to drinking the Iteratee Kool-Aid in order to write safer networking code that is still performant. Here are a few projects I'm actively working on in this area:
While much of this isn't quite ready for use yet, this just represents one person's work, and there are lots of people beavering away actively at corners of the problem space that interest them.
- I'm adding epoll support to the threaded RTS. This is a necessity for server performance.
- I've added support for sending and receiving lazy ByteStrings to Johan Tibbell's network-bytestring library. A quick benchmark with a toy HTTP server has shown this to be about 2x faster than writing ByteStrings to a Handle (i.e. 14,000 requests per second, vs 7,000).
- I've got a continuation-based resumable parser combinator module for attoparsec in progress, which uses lazy ByteStrings for blazing performance. You can use this to write protocol parsers in a completely clean way, decoupled from the underlying network receive operations.
I actually think that we're very close to being in fantastic shape here. I'm working on a memcached client library that uses the above libraries, and it's faster than the absolute best C memcached client (libmemcached), while also far smaller and elegantly layered. As a community, we are developing many proofs that you can have beautiful code without sacrificing performance.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe