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

Actually, the class will get loaded as long as it is referenced from 
some class that has been loaded. The static initialization may slow it 
down at startup, and also in the off chance that there is an error while 
instantiating the instance, the class will fail to load.

I do not think the synchronization burden is too high though, 
particularly since there is really no contention for the lock.

I am in favor of leaving it as is.

Thanks,

Sumeet

Philippe Verdy wrote:

>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
>
>.
>
>  
>

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