[threeten-dev] [threeten-develop] #176 Cnveret ZoneRules from interface to calss
Xueming Shen
xueming.shen at oracle.com
Thu Dec 20 17:55:15 PST 2012
On 12/20/12 5:11 PM, Stephen Colebourne wrote:
> On 21 December 2012 01:08, Xueming Shen <xueming.shen at oracle.com> wrote:
>> I'm not sure if we want to have an extra public factory method of(ZoneOffset)
>> to simply for better memory performance when being created from
>> ZoneOffset.getRules(), which probably will not happen in normal scenario.
> ZoneOffset.getRules() will be called a lot via ZDT. It is vital to
> have the extra factory so we can optimise later. Just constructing the
> empty lsts and passin 5 arguments rather than 1 is an overhead.
We definitely need to come back and address this issue. Even with the
specific
factory method and an optimized version of ZoneRules, we probably still have
a bigger issue with the current design/implementation, if
ZDT.getZone().getRules()
always creates a new rules object when the zone is a ZoneOffset.
I will add a of(ZoneOffset) to rest the case for now.
>
> Stephen
>
>
>> The webrev has been updated for your other comments.
>>
>> I will try to see if we can have a better option.
>>
>> -Sherman
>>
>> On 12/20/2012 04:52 PM, Stephen Colebourne wrote:
>>> On 21 December 2012 00:22, Xueming Shen<xueming.shen at oracle.com> wrote:
>>>> On 12/20/2012 04:07 PM, Stephen Colebourne wrote:
>>>>> The rules for offsets are created and thrown away rapidly, whereas
>>>>> ZoneId rules are cached. Thus I think we should keep the special
>>>>> implementation for offsets (as a hidden inner class). It is likely to
>>>>> have much better performance and garbage collection because it is
>>>>> simpler.
>>>> Agreed. But the problem is that we want to return a ZoneRules, which is
>>>> supposed to be final... There should be not too big impact to the memory
>>>> footprint, given those a singleton empty list or zero-length array, but yes,
>>>> ideally we can have a simple representation for this special case.
>>> A non-final class with a package-scoped construcor can be considered
>>> to be immutable if all the fields it holds are declared final.
>>>
>>> We're talking about 16 extra bytes per instance created, which isn't
>>> ideal. If the other fields were null it may help the gc more than
>>> having empty arrays.
>>>
>>> Perhaps we could invert the internal hierarchy. Have the simple
>>> implementation as ZoneRules and the complex implementation as the
>>> subclass? A little weird, but effective in memory usage, and hidden
>>> from most users.
>>>
>>> I'd suggest you start by adding the extra factory method, and maybe
>>> push that. The internal optimisation can then come later.
>>>
>>> Stephen
>>>
>>> ------------------------------------------------------------------------------
>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>>> Remotely access PCs and mobile devices and provide instant support
>>> Improve your efficiency, and focus on delivering more value-add services
>>> Discover what IT Professionals Know. Rescue delivers
>>> http://p.sf.net/sfu/logmein_12329d2d
>>> _______________________________________________
>>> threeten-develop mailing list
>>> threeten-develop at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> Remotely access PCs and mobile devices and provide instant support
>> Improve your efficiency, and focus on delivering more value-add services
>> Discover what IT Professionals Know. Rescue delivers
>> http://p.sf.net/sfu/logmein_12329d2d
>> _______________________________________________
>> threeten-develop mailing list
>> threeten-develop at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/threeten-develop
More information about the threeten-dev
mailing list