MetroTwit's A Little Hungry

When it comes to Twitter clients for Windows, MetroTwit is by far my favorite. I've tried a good portion of them; from TweetDeck to Seesmic (Air, Desktop, and Web) to various Chrome extensions, but none of them offer most of what I'm looking for. MetroTwit, while still missing a few things, is visually and functionally the best I've used on Windows. That said, there are times when I'm at a complete loss for words.

Take today's situation, for example. Here is a screen shot of MetroTwit as it appeared at 8:30 pm today. Nothing strange about this ... just my standard three columns with no fancy stuff. It's been running for the last 14 hours on my secondary monitor.

MetroTwit | ScreenShot

Nice and simple with a clean interface and, since the 0.7.0.1 update, a very responsive UI. So looking at what's above, I can't make it equate to what's below:

MetroTwit | Memory Usage

I can't help but wonder if someone's forgotten to include some resource scrubbing routines into the application. How else can one explain why a text-based application, while wonderfully designed and responsive, would need so many resources?

The application is using the .NET Framework, a system I have spent most of my programming career utilizing, and I understand that there are lots of places where memory can be consumed, marked for release, but never actually released ... but this is quite excessive, even for a .NET app.

The program will undoubtedly get better with each update. I've seen this first hand with the transition from 0.5.0 all the way up to the current build. It's just a matter of time. That said, while we're waiting for a memory-light update to this excellent Twitter app, people with resource-constrained machines will need to pay close attention to their resource monitors.

Speaking of which, if you haven't already downloaded MetroTwit, I strongly urge you to. It may be a pig on resources when left running for half a day, but it's really one of the best Twitter clients for Windows.

Page generated in roughly: 0.56344 Seconds, 0 API Calls, 8 SQL Queries, 6 Cache Objects