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

From: "Roger Kapsi" <[email protected]>
> On Jul 25, 2004, at 6:36 PM, Philippe Verdy wrote:
>
> > 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.
>
> Huh? :-/ But the initialization is delayed in both cases after
> application startup. As I said, the static variable gets only
> initialized if someone calls SchemaReplyCollectionMapper.instance() the
> first time and this is not different from the current implementation!?

OK. Anyway, this class is not so critical in my current usage pattern
snapshots, and it is not so complex that it will take much resource to
setup. So I agree that lazy initialization is not so fruitful here, and your
optimization simplifies the code...

> Note: SRCM is initialized by MetaFileManager quite early at startup and
> DaapMediator will make usage of it as well. So this class it's not
> limited only to searches.

Thanks for pointing it, I did not search a lot within that part of the code,
and did not see that dependency.

As I said, most of the optimizations that remain to do is within the
Gnutella message handling code that use too many temporary objects, and that
limit the performance of UltraPeers, which still use too much memory when
they run in the background with many leaf connections:

I'm quite sure that we could reuse some message structures, at least within
the same connection thread (if we don't share these objects in a single pool
difficult to synchronize). This is will most useful for UP-to-UP
connections, that already handle a large volume of Gnutella messages with
too much memory footprint.

Also I don't like the way some messages are handled: they are parsed in
several levels, breaking a single message into several subobjects, notably
for the GGEP extension lists... Here again, we should be able to represent
all GGEP extensions within a single shared object for their backing store,
instead of breaking the message into many fragments with extra allocations
and copies:

- in each connection thread, the messages are handled one after the other,
and so each message could be handled in the same object than the previous
message already processed;
- its backing store should be directly accessible when parsing GGEP options;
- if an option needs to be decompressed, it should be done within a
decompression buffer reusable for the next message.
- when building new messages for responses, the connection thread should be
able to use its own pool of output buffers; we should be able to create
responses without using message constructors, but using that local pool and
sending it to pool accessors with the necessary options to fill the
messages...
- if needed, connections could be cleaned routinely to free up unused space
in their pool. This could be done by using the timeout parameter in the
connection listener: no message was received in the socket but the
connection thread can initiate this cleanup; this will help maintaining the
size of the internal pools low in each connection thread, so that an
ultrapeer with lots of connections will not explose its global memory with
lots of unused buffers in many threads.

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