[YoThisBling]

CPU % increase
4.11.1 and 4.11.2 betas, the CPU% increases much more than previous releases.

CPU% spikes to 90% for a long period of time.
What is the casue of this?

[stief]

I'm not sure of the cause, because I'm on a Mac and have had Apple and Java problems for a while.

on a G4 running 10.4.6 and Java 1.5, I've noticed CPU as much higher than before. 25% used to be expected, but with the betas it is up to more than 40%, and frequently at 70%.

Can't say I've noticed any steady 90% though. How much RAM do you have?

[Sam]

Yes, the CPU will be slightly higher with the newer versions. Older versions had an artificial limitation on the bandwidth, which kept the CPU lower but reduced the overall network bandwidth. We've removed this limitation, so downloads and uploads should become much faster as people upgrade, but the CPU will be a little bit more taxed.

[stief]

a "little bit more taxed" I expected. But should double or more CPU use be expected? I really haven't changed my upload/download habits significantly . . .

Can the LW tests give an approximate % of what increase we should expect?

[YoThisBling]

Originally Posted by stief

I'm not sure of the cause, because I'm on a Mac and have had Apple and Java problems for a while.

on a G4 running 10.4.6 and Java 1.5, I've noticed CPU as much higher than before. 25% used to be expected, but with the betas it is up to more than 40%, and frequently at 70%.

Can't say I've noticed any steady 90% though. How much RAM do you have?

I have 1 GB of RAM and it has stayed around 90%.

[Agent_J]

LimeWire 4.13.0 Beta still seems to have this problem, any chance these suggestions could be (re)implemented?

http://www.limewire.org/techdocs/performance.htm

[Sam]

Sure.

Add support for non-blocking IO, which greatly reduces the number of threads.
Mostly finished a few versions ago, 99% finished with 4.12.

Reduce startup time by delaying the loading of inessential GUI components, like the options window.
Finished many versions ago.

Optimize connection initialization/handshaking. There appears to be a number of reasons for poor performance. First, the calls to HostCatcher.add can be too slow, which is called for every X-Try/X-Try-Ultrapeer address in connection handshake headers. Second, the act of actually sending and receiving headers (in AuthenticationHandshakeResponder and subclasses) can be slow.
Finished many versions ago. The whole Authentication series of classes removed, HostCatcher.add takes a trivial amount of time to run, and X-Try headers are very rarely used.

Reduce memory footprint of query routing (QRP) tables. Currently we allocate a whole byte per entry; we only need a bit.
Finished many, many versions ago.

A better approach might be to use a single route table for all connections. Each entry of this table would be a list of all connections matching that index,
Finished many, many versions ago.

Optimize message writing in ManagedConnection. Writing a message involves queuing a message and notifying its associated output thread. The output thread then removes the message from the queue and writes it to the socket. There are two things to optimize: the overhead of wait/notify and of manipulating the queue. The latter is easier to optimize.
Finished with the introduction of NIO. The thread overhead is obliterated because there's no more threads, and queue performance is vastly increased.

Also, it should be possible to reduce the memory footprint of these queues. Leaf connections may not need the full SACHRIFC buffers, for example. It is probably not necessary to preallocate a fixed amount of memory for these buffers when they are typically mostly empty.
Leaves still have SACHRIFC-type buffers set up, but memory is lazily allocated for them.

At the least, we should avoid allocating these buffers until the connection has been initialized and accepted for normal use.
Done with the introduction of NIO (although it's unrelated).

Reduce the memory footprint needed to display search results.
Done many versions ago.

Optimize ConnectionManager.hasClientSupernodeConnection. Currently this method can use up to 20% of all CPU time. The problem is that it iterates through all connections, which requires cloning the array. This method is called from allowAnyConnection, which is called when accepting new connections or handling pings. A better approach is to simply to augment ConnectionManager with a boolean that is true iff one of the connection is a leaf to ultrapeer connection. Be sure to maintain the invariant when adding and removing connections.
Done many versions ago.

Optimize the creation of GGEP extensions in pongs. Currently it can consume 20% of all message handling time. The problem is too many calls to StringBuffer.append from PingReply.write, which is called from PingReply.newGGEP from the PingReply constructor.
So very done.

Optimize route table GUID lookup. Currently we use TreeMap to back our RouteTable data structure. I can't remember why we don't use HashTable's; I think it has to do with performance problems from resizing the tables. I would be curious to try splay trees, a randomized data structure. Splay trees can outperform standard dictionaries under irregular access patterns, e.g., when handling a stream of query replies with the same GUID..
Not done, but not really a problem still.

We should probably update all those documents. Pretty much every one is grossly out-of-date.

[stief]

Thanks for taking the time to summarize all those improvements. . . amazing how much has been done, especially with NIO.

Still, twice the CPU has stuck way high (+90%) on a Linux system (after running more than a couple of days continuously) . Initially the CPU usage, even as an UP, was very low--6-10%

I figured it was my inexperienced setup in Linux, so I wiped the drive and reinstalled from scratch. Then it happened again.

Quick tips for capturing this on Linux much appreciated.

[vip8439]

Mine usually spikes at %100 and I cant switch between opened windows without waiting for 5 minutes. I have a 1.8 Ghz CPU and 512MB of RAM. This happens in XP, Server 2003, and Fedora Core. I'm kinda surprised to see it is a removed artificial bandwith limitation that is the culprit. In a post I've read before, LimeWire said it was a Java bug. That may be so, but its kind of funny how none of my other Java applications bring my computer to a halt. Also funny how I can run Doom3 at a very acceptable rate, but LimeWire brings my comp to its knees. What are the developers using? Quad, Intel Core 2 Duo machines for testing? Whatever it is, I wish LimeWire would fix it. I'm very tired of this and really don't care for many of the P2P alternatives except for Ares.

[Sam]

Very very few other Java programs have as intense a network stack as LimeWire. We kind of use Java to the extreme.