I feel silly asking, but who or what is 'rtm'?
1: https://secure.wikimedia.org/wikipedia/en/wiki/Robert_Tappan... 2: same acronym as RTFM , but polite.
Read The Friendly Manual. How much more polite can you be?
Why HN was slow and how Rtm fixed it
181–190 of 202 posts
Re: Why HN was slow and how Rtm fixed it
#182Earlier quoted context omitted.
Pagination/"More" uses fnids; looking at the source it's a callback, but from an HTTP client perspective it might as well be a continuation. How do you test and debug things like that that have random URIs and function names and get GCed on a regular basis? That's what I mean when I say continuations lead to unmaintainable web apps.
I've been using this technique since 1995 and it has never once been a problem. It's an instance of programming with closures, which has been common in the Lisp world for even longer. One doesn't need to examine something represented as a closure any more than one needs to examine a particular invocation of a recursive function. Perhaps the reason I've never had a problem is that I've been careful to use this techniq…
It's a problem for me when the fnids in every reply cause them to expire several times a day when the server crashes.
Edit: also when the server redirects me back to the wrong origin, I was sent to http://news.ycombinator.com/threads?id=pg instead of http://news.ycombinator.com/item?id=2120756 after posting this reply initially.
Re: Why HN was slow and how Rtm fixed it
#183Earlier quoted context omitted.
Feel free to fork MzScheme and replace the garbage collector with a new one that runs continuously.
I love this response. Would be really interested in a follow-up from axod (or by pg about axod's version). It's easy to criticize, but let's see what happens when the pedal hits the metal.
My response TBH, would be that there is no point spending months tweaking the engine of a ford to try and get it to perform like a porche. Just get a porche in the first place.
I don't value "being able to write it in my favorite language" at all. From what I've read, pg does. To the extent that the product suffers.
There would be absolutely no point me trying to improve mzScheme when you can do exactly the same job in other languages/platforms, and the user doesn't care/know the difference. HN could be rewritten in a weekend, in PHP/python/whatever and we wouldn't be sitting here waiting for pages to load.
(I run Mibbit, which handles a few thousand HTTP requests a second, on VPS level hardware. In Java).
Re: Why HN was slow and how Rtm fixed it
#184Earlier quoted context omitted.
I love this response. Would be really interested in a follow-up from axod (or by pg about axod's version). It's easy to criticize, but let's see what happens when the pedal hits the metal.
My response TBH, would be that there is no point spending months tweaking the engine of a ford to try and get it to perform like a porche. Just get a porche in the first place. I don't value "being able to write it in my favorite language" at all. From what I've read, pg does. To the extent that the product suffers. There would be absolutely no point me trying to improve mzScheme when you can do exactly the same job…
Neither Python nor PHP run garbage collection continuously in a separate thread. Python is reference counted, and as far as I know PHP is too.
Re: Why HN was slow and how Rtm fixed it
#185still takes about 7 seconds to load, don't feel like something has been fixed.
Re: Why HN was slow and how Rtm fixed it
#186Earlier quoted context omitted.
My response TBH, would be that there is no point spending months tweaking the engine of a ford to try and get it to perform like a porche. Just get a porche in the first place. I don't value "being able to write it in my favorite language" at all. From what I've read, pg does. To the extent that the product suffers. There would be absolutely no point me trying to improve mzScheme when you can do exactly the same job…
Neither Python nor PHP run garbage collection continuously in a separate thread. Python is reference counted, and as far as I know PHP is too.
But I'd bet both of them perform far better than MzScheme.
In any event, it's a "solved problem". The sheer amount of time and effort going into this is silly. Just pick a better language/platform and use it.
Re: Why HN was slow and how Rtm fixed it
#187Earlier quoted context omitted.
I think that all depends on the purpose of the site. If I were paying a subscription to access the site I would be within my rights to object. As it is, with HN being a free service, built to be the application spurring the development of Arc, whose reference implementation is intended for exploring language design and not performance, I wouldn't choose the word "shameful" to describe this situation.
I guess it depends on your priorities. Personally, I think the community discussion here is far more interesting than the toy language project it runs on. If you think Arc is the future of computing you may think of this discussion board as just a convenient test suite for the language. Either way, it's 2011 and that really is some spectacular slowness.
My comment was not expressing an opinion on the relative values of Arc and the HN discussion community. HN delivers lots of value for the modest price of your time. Claiming that its performance is shameful when it isn't being directly monetized, or even indirectly monetized like Facebook &co., is unfair.
If you were talking about Facebook, Twitter, or Basecamp, that would be a different matter.
Re: Why HN was slow and how Rtm fixed it
#188Earlier quoted context omitted.
Pagination/"More" uses fnids; looking at the source it's a callback, but from an HTTP client perspective it might as well be a continuation. How do you test and debug things like that that have random URIs and function names and get GCed on a regular basis? That's what I mean when I say continuations lead to unmaintainable web apps.
I've been using this technique since 1995 and it has never once been a problem. It's an instance of programming with closures, which has been common in the Lisp world for even longer. One doesn't need to examine something represented as a closure any more than one needs to examine a particular invocation of a recursive function. Perhaps the reason I've never had a problem is that I've been careful to use this techniq…
> I've been using this technique since 1995 and it has never once been a problem.
Thousands of HN users experience the problems every day: link expired.
Re: Why HN was slow and how Rtm fixed it
#189Earlier quoted context omitted.
I've been using this technique since 1995 and it has never once been a problem. It's an instance of programming with closures, which has been common in the Lisp world for even longer. One doesn't need to examine something represented as a closure any more than one needs to examine a particular invocation of a recursive function. Perhaps the reason I've never had a problem is that I've been careful to use this techniq…
> I've been using this technique since 1995 and it has never once been a problem. Thousands of HN users experience the problems every day: link expired.
I get the same problem on Reddit, except they call it "there does not seem to be anything here".
Re: Why HN was slow and how Rtm fixed it
#190Earlier quoted context omitted.
Read C10K? Both select() and poll() have this problem internally. You have to use one of the more advanced techniques available if you really want to scale. epoll(), kqueue() or friends.
poll() is slightly better than select(), because you only have to iterate over the file descriptors that were passed, rather than from 0 to nfds.
It doesn't hurt that its interface is far more pleasant to use than select's, either.