Interesting RIAA DOS idea, Zarcuthra, but it doesn't seem to jibe with my seeing reduced network activity during episodes of particular slowness/unresponsiveness.

Also, it's bloated back up to 105MB and I just had the UI lock up for a couple of minutes, about 30 items currently in the download list and still sharing 9433 files. No complaints that 1GB is not enough from it yet this session though.

I think we have three problems here:
1. It's inefficient -- sharing 9433 files makes it need 95MB? Assuming the mem usage in a clean install is around 30M (which, though high, coincides with most of the major browsers such as Firefox), this is about 6500 bytes more for each shared file. How much of that really has to be resident all the time and how much can be retrieved when the file's requested? It seems to me only the filename and maybe metadata for matching and maybe the hash need to remain in RAM at all times to match against incoming queries -- and for leaves shielded by ultrapeers (including my node), not even that. The info needs to be sent to ultrapeers upon connection (and reconnection) and then ultrapeers manage routing queries to me only if I have matches on my system. So, I'd say zero bytes need to be resident per shared file on average!

Add to that that adding about 30 downloads made it bloat to 105, or 20 more megs, suggesting an astounding 600K(!) of resident data for each item. That's assuming, of course, that it doesn't leak, which since it's Java it shouldn't.

Why does it need 600K (not bytes, K!) per download list entry? Earlier versions didn't -- 3.3.5 could have 2000(!) download items and run OK on a half-gig machine. That means, assuming it used all available RAM for just resident download information, it used at most 256K per download item. I find it unlikely it used even that much. In fact I think:

2. It leaks. Despite running in a garbage collecting environment, it leaks. I guess never-to-be-used-again objects remain reachable. Does it create and then discard circular data structures? Some GC implementations (reference counting, for one) won't discover that two objects are garbage if they each refer to the other but nothing else refers to either. I hoped Java's wasn't among them, but the fact is Limewire seems to leak memory. And recent versions (4.0 and above) seem to hemmorhage memory.

3. Like some archaic, long-forgotten MS-DOS applications, it doesn't recognize all of the installed memory. While those DOS applications recognized only 640K (which "ought to be enough for anybody", according to Bill Gates), even if you had several megs XMS or *** memory, Limewire seems to recognize 128M. That's an improvement, but it's not enough. Obviously. This, I think, is the only logical explanation for it reporting "out of memory" errors when its process size is around 120M and the system still has gobs of free ram. It's that, or it's trying to allocate hundreds of meg in one chunk, or it's lying altogether. Anyway, there's no excuse for not using as much RAM as needed out of all that's available on a modern 32 bit platform with protected mode flat virtual memory addressing. This isn't MS-DOS or the ancient hoary versions of MacOS where every app had a fixed allotment of RAM and hairy near and far pointers and segments and offsets were commonplace programming vocabulary. The only case now where per-application memory restrictions make sense is in some circumstances involving multi-user time sharing systems. And since my box isn't one of these, it's a single user home machine, I should be able to turn any such restriction off. If there is such a setting buried in the bowels of Limewire I've been unable to find it, either in the options dialog or with a hunt for Limewire-related registry keys in regedit or by opening every ascii file in either Limewire's program directory or its settings ".limewire" directory in a text editor! This suggests if such a "feature" exists, it was, in a true display of archaism, hard-coded without any way at all for end-users to alter it to suit their particular circumstances! That's really stupid. Hard-coded limits can't be outgrown without changing and recompiling the source, which most end-users can't be bothered to do even with open source stuff and can't do with closed-source, and Moore's Law makes the outgrowing of such limits inevitable. Not foreseeing the need to revise them upward on high end machines in the near future is like not foreseeing that using a two-digit field to store dates was going to be a problem in a few years' time back in the 1990s -- and yet there was software written in that decade that needed Y2K fixes.

Of course, people had to pay for those fixes. Could this be built-in obsolescence? A way to force Pro purchasers to buy upgrades to keep their Limewire functioning as the machines have more and more RAM and user tasks demand more and more? I hope not. That would indicate very underhanded motives on the part of the development team. And why put a built-in obsolescence restriction in the free version? I suppose to motivate people to buy pro? It won't work -- all it does is make people try Limewire Basic, think "This runs like a pig and crashes all the time with memory errors on my gigabyte machine! I'm not paying for crap like this!" and switch to Gnucleus. Which doesn't work with Zonealarm, unfortunately, or I'd switch to Gnucleus!