The Search for an Aggregator Continues
SharpReader, which I enjoy using immensely, has started leaking memory like a sieve with release 0.9.2. It was already a memory hog, sucking up more than 60 megs of memory regularly, but with 0.9.2, it began sucking up every last bit of available memory. Sigh. I emailed Luke this morning, but in the meantime I have an unusable aggregator and miss my feeds. Rolling back to version 0.9.1.3 alleviated the problem leakage problem . . . but 50-75 megs of memory is still too much for an aggregator to use.
So I’m shopping around for a new aggregator for Windows. Someone at the MERLOT conference recommended Awasu, but it appears their freebie version doesn’t include support for importing subscriptions from an OPML file, and I don’t feel like paying just to find out whether it can handle the 150+ subscriptions better than SharpReader.
Recommendations?
UPDATE (5:00pm): I purged an enormous amount (thousands) of old posts from SharpReader and that brought it’s memory footprint down to about 54 megs. Could it be that SharpReader is loading the entire feed for each subscription into memory?!? That would be crazy! Yet it appears that the amount of memory SharpReader consumes is somehow related to the number of posts in each feed. :-/
Check out the list on my site. ;)
Found the list.
Now which are the good ones?!?
:-)
The free version of Awasu can import from OPML. Open the Plugins tab in the Control Center and choose the ImportOpml plugin. It will import all of your channels but when it runs, it will just ignore any past the first 100.
Awasu generally runs at around 20-30 Mb on my machine but most of that seems to be because of the embedded IE. It’s been a while since I’ve done heavy stress-testing but IIRC, if I didn’t open any windows, it ran at The free version of Awasu can import from OPML. Open the Plugins tab in the Control Center and choose the ImportOpml plugin. It will import all of your channels but when it runs, it will just ignore any past the first 100.
Awasu generally runs at around 20-30 Mb on my machine but most of that seems to be because of the embedded IE. It’s been a while since I’ve done heavy stress-testing but IIRC, if I didn’t open any windows, it ran at < 10 Mb. As soon as you loaded IE, it jumped up and then stayed there :-(
Oops. Forgot to escape a < :-)
What I meant to say was: if I didn’t open any windows, it ran at < 10 Mb. As soon as you opened a browser window, it jumped up and then stayed there.
Thanks for the tip! Of course, the 100-feed limit means I wouldn’t be able to use the free version for anything other than evaluation purposes (which, of course, is the idea of a free evaluation version, duh, greg).
Um, yes and no.
The free version is fully-featured and not just an “evaluation” version. I’ve made a point of making sure that virtually every feature that’s in the paid version is also in the free version in some form.
For most people, 100 channels is more than enough and they can quite happily use the free version. If you have more than that, then you’re probably a serious RSS user and if you like Awasu, it’s not that expensive :-) If you’re interested, send me an email and I’ll knock up a special build for you.
SharpReader may be using DOM-based XML-parsing, which means it reads in the entire XML text file then “compiles” it into an object you can do queries on, etc. Event-based parsers read in the file progressively and takes action when it comes across specific tags. The former has advantages in allowing complex interactions and queries against a parsed XML document, the latter has the advantage of being much faster.
Taka — Thanks for the feedback and offer of assistance. I’ll take a closer look at Awasu.
Anthony — Thanks for the explanation . . . although to me your comments sound like the teacher on the old Charlie Brown cartoons: “Mwu mwah mwah mwahh. Mwah. Mwah MWAH!” ;-)
Ooh! Can I make a poor analogy?
So you want some cookies, chocolate-chip ones to be exact. You have a huge bag of cookies of all kinds, and set your cookie parser to give you the chocolate-chip ones.
If he was a DOM-based cookie parse, he’d take all the cookies and sort them into neat piles by content. Once he had finished, he’d hand you the pile of chocolate-chip ones.
Now, if he was an event-based cookie parser, he’d put all the cookies in one pile to his left, and go through each cookie individually. If it was chocolate-chip, he’s give it to you right away, otherwise he’d put it in a pile to his right.
Both styles have advantages and disadvantages. Mr. DOM-based cookie parser takes longer to give you the cookies the first time around, but any subsequent requests (say for oatmeal-raisin) would take almost no time at all. Mr. event-based cookie parser starts giving you cookies as he finds them, but doesn’t otherwise organize them; asking for oatmeal-raisin would make him go through the cookies all over again.
Damn good analogy! Now I’m hungry, though. :-)