3 ms·

If Yesod is about performance, it's not showing: http://www.techempower.com/blog/2013/04/05/frameworks-round-2/ http://www.techempower.com/blog/2013/04/05/frame

• polymatter 14y ago
  Well, thanks for the data.
• DannoHung 14y ago
  Be sure to check community commentary on the implementations that were tested before deriving any conclusions: http://www.reddit.com/r/haskell/comments/1bqsvi/web_woes_for_haskell http://www.reddit.com/r/haskell/comments/1bqsvi/web_woes_for...
  • profquail 14y ago
    For the lazy: The reason for Yesod's poor showing in that benchmark was due to a flaw in the implementation of the benchmark. A certain function (newSTDGen) was called repeatedly within each request, even though it should have only been called once; it's a relatively "expensive" function so this had a large impact on the results of the test. In addition, the Yesod test used TCP sockets to communicate with MySQL while the other frameworks were set to use UNIX sockets. This has also been found to have a non-trivial impact on performance, as discussed in this SO thread: http://stackoverflow.com/questions/257433/postgresql-unix-domain-sockets-vs-tcp-sockets http://stackoverflow.com/questions/257433/postgresql-unix-do...
    • papsosouid 14y ago
      >A certain function (newSTDGen) was called repeatedly within each request It is called zero times in the json benchmark, which yesod still did quite poorly on. That is only a factor in the "pull a random thing from the DB" test. I believe the biggest underlying issue was that sessions are enabled, which means transmitting more data (the cookie) as well as doing encryption and HMAC on the cookies. Disabling sessions doubled the performance.
• deleted 14y ago
  [deleted]
• deleted 14y ago
  [deleted]