First, the nice people at #haskell (specifically it was <sm>, but there were many other helpful people there like <ksf> and others whose names I won't remember) made me swtich from fastcgi to warp. I didn't think it would be relevant, since my performance problems were all memory-consumption-related, but it turned out to speed my code by orders of magnitude. Everybody switch to warp! :-) Second, I've been thinking about the performance bounds of a Yesod app. As in, given an app that has no leaks etc', where can I expect it to perform better than imperative languages I'm familiar with, where can I expect it to perform worse? The biggest limits imposed by Yesod that I thought about were: * [Char] - not in Yesod 0.8 * Persistent always takes a full row - shouldn't matter much in practice, especially if persistent is lazy and doesn't parse columns I don't care about * No joins in DB - being solved as we speak * All page must be generated before it is sent if we plan to use Widgets -- Well, this one is interesting. It seems to be very much against Haskell nature, that is so lazy and nice, and I think in my code it might actually make performance difference. So I thought -- isn't it possible to extend Hamlet to work in an Iteratee too? What do I mean? Something like: rows <- selectEnum ... hamletAction [$hamlet| <html> <head> <body> $for row <- rows <p> #{rowDescription row}
(c) Aur Saraf etc' etc' That would expand to a monadic action that creates chunks of HTML while reading the rows Enumerable. Is there any serious technological problem with this approach? Or just choosing a nice extension of Hamlet that would allow running monadic actions in it like functions are allowed today, without affecting the simplicity of the API? Cheers, Aur PS Michael, is it possible in Yesod to have two selectEnum-s "running" at the same time? Otherwise you'd only be able to work with one query at a time in this way...