3 ms·
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) wa
by 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.