So with and without caching the performace was the same? I suggest
dropping the caching and keeping the memory savings from the changes to
OneByte.

-----Original Message-----
From: Firebird-Java@yahoogroups.com
[mailto:Firebird-Java@yahoogroups.com] On Behalf Of Roman Rokytskyy
Sent: Wednesday, June 21, 2006 1:39 AM
To: Firebird-Java@yahoogroups.com
Subject: Re: [Firebird-Java] Possible memory leak in EncodingFactory ?

> So I reason the slow-down must be in the pooling. It would get even
> slower when changed to a SynchronizedHashMap or ConcurrentHashMap.
> Let's test with just the memory reduction for now and see what those
> numbers generate.

The number are comparable. I guess we stop here. The implementation of
Encoding interface will be "cached" for the lifetime of the XSQLVAR
object, won't have allocated memory except the one for the object
itself.

Thanks!
Roman



------------------------ Yahoo! Groups Sponsor --------------------~-->
Yahoo! Groups gets a make over. See the new email design.
http://us.click.yahoo.com/XISQkA/lOaOAA/yQLSAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links