[gui-dev] Re: [codepatch] A small optimization for SchemaReplyCollectionMapper

----- Original Message ----- 
From: "Roger Kapsi" <[email protected]>
To: "Philippe Verdy" <[email protected]>
Cc: <[email protected]>
Sent: Friday, July 23, 2004 8:01 PM
Subject: Re: [codepatch] A small optimization for
SchemaReplyCollectionMapper


> Hi Philippe,
>
> I'm maybe missing something but how does this has an impact on the
> launch time or memory usage? In both cases the static class variable is
> being initialized if SchemaReplyCollectionMapper is touched the first
> time and never if no one touches it.

I know that, but I don't think there's any access to the instance accessor
before the user actually starts an active search, so this initialization is
delayed after application startup.
In the past, LimeWire was considered very slow to start because too many
classes needed to be loaded and instanciated to create singleton instances,
meaning that LimeWire could not start without loading, initializing and
instanciating immediately nearly all of its classes; on a system with less
than 128MB RAM, the launch time was really prohibitive, notably for PCs or
MAc with processors less than 1GHz.

This had an impact on what users feel about LimeWire: its immediate memory
footprint, intense VM swap at startup, and too many users disconnecting it
instead of letting it run in the background.

Of course many efforts have been invested in the core's code to reduce the
number of temporary objects allocated when LimeWire is running (notably many
temporary StringBuffer's or Strings, and tuning ArrayList's with a better
preallocation size to limit the number of reallocations).

Other efforts have been invested in creating accessors to reusable utility
objects like the XML parser, or the HTML engine, or the files hasher.

There are still efforts to put there, to maximize the reuse of temporary
work objects, notably in the handling of messages and their parsing (which
is today, along with draw buffers for the display, the most active source of
temporary objects that stress the VM garbage collector).

There are everywhere in the code many places where we can limit the use of
internal work objects, and this is visible when you create a VM snapshot and
consider their lifetime, or the large size of the active part of the VM.

On my Pentium Mobile Centrino 1,9HGz with 1MB RAM, LimeWire is a pleasure to
use, but this config is still far from the average config of candidate
LimeWire users. As long as LimeWire will be so CPU and RAM intensive, other
servents will compete with it (notably eMule, or even BearShare).

_______________________________________________
gui-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/gui-dev