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 2009/1/8 Bryan O'Sullivan <b...@serpentine.com> > On Thu, Jan 8, 2009 at 1:07 PM, Manlio Perillo > <manlio_peri...@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: > > - 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. > > 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 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 > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
