Hacker News Reader

Comment by tedunangst | Hacker News Reader

I wouldn't advocate for slower software, but is all of this really necessary for a fast RSS reader? My RSS reader downloads the entire XML file as blob, parses it into an array of structs, then walks over the array looking for new links. It's not particularly slow. I can't imagine it would be worth optimizing this aspect of the code base.

View on HN

I don't know if it's "necessary," but you can really see the speed difference between NetNewsWire and, say, Reeder on the same hardware. It's not that Reeder is slow, it's that NNW is just really fast.

> I can't imagine it would be worth optimizing this aspect of the code base.

Well, this is the code path taken when the news reader is starting up or refreshing, right? It feels to me like that's the most important place to optimize an RSS reader, because it has a direct impact on the time between when the user clicks the "Refresh" button and everything is updated. Even if the user doesn't actually need to sit there and do nothing when it's updating, if updating takes 3 seconds instead of 10, it makes the whole experience feel much faster.

FWIW, I find Reeder to be faster and slightly more reliable than NNW on the same hardware. I'm switching to NNW anyway because the UI is so much better. Reeder's custom UI feels fluid, but it's really easy to do things like accidentally mark lots of articles as read and then delete them from the local cache. For some things, the boring, native UI is really the best UI.

Interesting -- I find NNW to be faster than Reeder on my hardware, but keep drifting back to Reeder because... hmm. I suppose because of its UI, even though I actually agree that NNW has a better UI. :) It's specifically because I like to have the newsreader only show me unread articles in my feeds unless I specifically switch it to "show all," hiding each article after I read it. That's something NNW doesn't do, and the affordances it has in that direction -- the "All Unread" smart feed view and the "Go to next unread" command -- aren't quite what I want.

Frequently, yes - profiling is important, of course, but feed readers disproportionately have power users who subscribe to many feeds, some of those can be very busy (e.g. monitoring or saved search services), and some people want a fair sized archive. When I first open a desktop reader app, I’m asking it to poll hundreds of feeds - it’s not a server running constantly - and easily many tens thousands of items before filtering. That means lots of repeated updates - and wanting that not to impact whatever is happening in the foreground.

Not critical but definitely noticeable - kind of like how the Atom editor had a bad reputation for input latency even if it was still usable, coloring your perception of the entire app.

I kinda overlooked that this has to be a desktop app. Having the program download 100 feeds when I open it seems suboptimal when it could have refreshed them all in the background, but I guess that's the way it is. Work that's already done is always faster than work you have to do, if that's an option.

Definitely- the original NNW and I believe this successor could use server sync to avoid needing to spend time polling things which hasn’t updated but it’s always been a bit more resource intensive than it seems at first, especially when they do things like diff-ing items to detect changes.

That’s just moving the problem down the pipeline. But it’s the same problem. You can have a daemon to update the data, but if the data is updated slowly, or if the UI is updated slowly after data update, the user experience is still terrible.

Sure, that's how quality software is built. And performance is a key part of quality software.

No optimization is worth the effort before profiling.

If they found out that these operations are responsible for long enough delays, or high enough energy consumption spikes, it would make all the sense to optimize them.

Profiling is good at telling you which parts of your code account for most of the program’s runtime, but that’s it. It can’t tell you whether the performance is reasonable relative to the work done, or whether a totally different approach is necessary. Writing fast code goes well beyond using profilers, in keeping with the article’s thesis.

Assume you locate a part of code which is 10x as slow as it could be. You make it 10x faster; great!

But that part only took 1% of the total perceived processing delay, so the user sees a whooping 0.9% improvement.

However, you need to have a big picture view or potential optimizations when you architect. The profiler can't save you from slow architecture.

The point here isn’t to do only what is “necessary”, but to do it because they care and want to.

Reply on news.ycombinator.com