On 6 July 2016 at 07:19, Kristian Rosenvold <krosenv...@apache.org> wrote:
> 2016-07-05 22:44 GMT+02:00 <c...@apache.org>:
>> LANG-1247: FastDatePrinter generates Date objects wastefully
>> closes #168
>> public StringBuffer format(final long millis, final StringBuffer buf) {
>> - return format(new Date(millis), buf);
Have a look at the format method.
It uses Calendar much as below.
>> + final Calendar c = newCalendar();
>> + c.setTimeInMillis(millis);
>> + return applyRules(c, buf);
>
>
> Arguably I might be a few years behind on developments regarding
> java.lang.Calendar within the JDK, but from previous experience the
> Calendar class is about as inefficient as things get, and anything
> touching the calendar sprays your heap with objects. As far as I can
> see, this just seems to be swapping around object allocation, probably
> to the worse (instead of one visible object allocation within
> commons-lang you're creating a fair bit of com.sun allocations as far
> as I know)
>
> I'd really like to see som evidence that this is an improvement, if
> nothing else to enlighten me :)
See above and the JIRA:
in this case the Date is *only* used to transport the long time to the
Calendar instance.
If you wish to eliminate Calendar in this case, that's another matter.
> Kristian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
