Hello Joel, Saturday, December 24, 2005, 9:29:17 PM, you wrote:
One of the interesting points that this illustrates (to me) is that the "obvious" approach in Haskell can be seriously non-optimal in terms of performance. Add to this the fact that tuning functional programs is a non-trivial art, and it becomes quite easy to see why Haskell might come across as slow.
JR> I got totally burned by this trying to write a heavily threaded, JR> heavy networking app in Haskell. The obvious approach was a dead-end. your problem is not Haskell or GHC, your problem is just lack of experience in this area. remember how i decreased number of your threads in 4 times, remember that i found simple and obvious solution for problem, what you tried to fix 2 weeks and ended with attempt to write your own scheduler. remember that you start low-optimizing "functional pickling" library, which is inefficient by its functional composition design instead of give chances to all serialization libraries and select the most effective one so i think that your problems is due to bad design decisions caused by lack of experience. two weeks ago when you skipped my suggestions about improving this design and answered that you will use "systematic approach", i foresee that you will fail and say that Haskell is a bad language Haskell is really slow language. but even if it will be 100 times better, it can't write programs itself, some help from programmer anyway is needed :) -- Best regards, Bulat mailto:bulatz@HotPOP.com