TimeFilterTest

[Ralph Goers <ra...@dslextreme.com>]

Is anyone else having problems with TimeFilterTest in core today?  I am in Arizona so we did not spring forward as we are MST all year.  I see the test is setting a timezone of America/Los Angeles.

Ralph

Re: TimeFilterTest

[Remko Popma <re...@gmail.com>]

Ralph,

No objection from me. 

Note that Java is getting better and better at escape analysis. We made use of this to implement our nanosecond precision timestamps in a garbage free manner even though we used a java.time API that produces immutable Instant objects. 

You may be able to do the same: immediately after calling the java.time API that returns some object, extract the primitive values from that object and don’t use that java.time object any more. If you need to call another method, pass the extracted primitive values, not the java.time object. 

If the filter can be implemented that way, it may still remain garbage free. (You can verify with our GcFreeSomething tests.)

If this is not possible, then just remove the garbage free label like you said. I agree that the impact will be limited. 

Remko



> On Mar 11, 2020, at 13:55, Ralph Goers <ra...@dslextreme.com> wrote:
> 
> I have modified TimeFilter to properly account for the change from daylight saving time to standard time and vice-versa. I also modified it to handle a start time on the day before the end time.  I have a suspicion that this filter is being lightly used because there are a whole lot of use cases where it wouldn’t work correctly. 
> 
> The problem is that to fix it I had to use java.time.  TimeFilter is flagged as being allocation free but java.time is anything but that. Almost every method creates a new immutable object.  I tried modifying the logic to use Calendar but I cannot figure out how to make it account for the overlapping hour in the fall whereas java.time easily handles that.
> 
> As a consequence I am thinking that I will remove the garbage free annotation from the filter. All this means is that it will perform allocations once per day.
> 
> Any objections?
> 
> Ralph
> 
>> On Mar 9, 2020, at 12:12 AM, Apache <ra...@dslextreme.com> wrote:
>> 
>> I started testing this. It doesn’t handle daylight savings at all and some of the tests make no sense. I’m rewriting it using java.time and implementing better tests.
>> 
>> Ralph
>> 
>>>> On Mar 8, 2020, at 11:19 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>>> 
>>> Is anyone else having problems with TimeFilterTest in core today?  I am in Arizona so we did not spring forward as we are MST all year.  I see the test is setting a timezone of America/Los Angeles.
>>> 
>>> Ralph
>> 
>> 
>> 
> 
> 

Re: TimeFilterTest

[Gary Gregory <ga...@gmail.com>]

+1

Gary

On Wed, Mar 11, 2020 at 12:55 AM Ralph Goers <ra...@dslextreme.com>
wrote:

> I have modified TimeFilter to properly account for the change from
> daylight saving time to standard time and vice-versa. I also modified it to
> handle a start time on the day before the end time.  I have a suspicion
> that this filter is being lightly used because there are a whole lot of use
> cases where it wouldn’t work correctly.
>
> The problem is that to fix it I had to use java.time.  TimeFilter is
> flagged as being allocation free but java.time is anything but that. Almost
> every method creates a new immutable object.  I tried modifying the logic
> to use Calendar but I cannot figure out how to make it account for the
> overlapping hour in the fall whereas java.time easily handles that.
>
> As a consequence I am thinking that I will remove the garbage free
> annotation from the filter. All this means is that it will perform
> allocations once per day.
>
> Any objections?
>
> Ralph
>
> > On Mar 9, 2020, at 12:12 AM, Apache <ra...@dslextreme.com> wrote:
> >
> > I started testing this. It doesn’t handle daylight savings at all and
> some of the tests make no sense. I’m rewriting it using java.time and
> implementing better tests.
> >
> > Ralph
> >
> >> On Mar 8, 2020, at 11:19 AM, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >>
> >> Is anyone else having problems with TimeFilterTest in core today?  I
> am in Arizona so we did not spring forward as we are MST all year.  I see
> the test is setting a timezone of America/Los Angeles.
> >>
> >> Ralph
> >
> >
> >
>
>
>

Re: TimeFilterTest

[Matt Sicker <bo...@gmail.com>]

Garbage free use cases typically have daily downtime (after trading closes
for the day for example), though admittedly I don’t know everyone’s use
cases.

On Tue, Mar 10, 2020 at 23:55 Ralph Goers <ra...@dslextreme.com>
wrote:

> I have modified TimeFilter to properly account for the change from
> daylight saving time to standard time and vice-versa. I also modified it to
> handle a start time on the day before the end time.  I have a suspicion
> that this filter is being lightly used because there are a whole lot of use
> cases where it wouldn’t work correctly.
>
> The problem is that to fix it I had to use java.time.  TimeFilter is
> flagged as being allocation free but java.time is anything but that. Almost
> every method creates a new immutable object.  I tried modifying the logic
> to use Calendar but I cannot figure out how to make it account for the
> overlapping hour in the fall whereas java.time easily handles that.
>
> As a consequence I am thinking that I will remove the garbage free
> annotation from the filter. All this means is that it will perform
> allocations once per day.
>
> Any objections?
>
> Ralph
>
> > On Mar 9, 2020, at 12:12 AM, Apache <ra...@dslextreme.com> wrote:
> >
> > I started testing this. It doesn’t handle daylight savings at all and
> some of the tests make no sense. I’m rewriting it using java.time and
> implementing better tests.
> >
> > Ralph
> >
> >> On Mar 8, 2020, at 11:19 AM, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >>
> >> Is anyone else having problems with TimeFilterTest in core today?  I
> am in Arizona so we did not spring forward as we are MST all year.  I see
> the test is setting a timezone of America/Los Angeles.
> >>
> >> Ralph
> >
> >
> >
>
>
> --
Matt Sicker <bo...@gmail.com>

Re: TimeFilterTest

[Ralph Goers <ra...@dslextreme.com>]

I have modified TimeFilter to properly account for the change from daylight saving time to standard time and vice-versa. I also modified it to handle a start time on the day before the end time.  I have a suspicion that this filter is being lightly used because there are a whole lot of use cases where it wouldn’t work correctly. 

The problem is that to fix it I had to use java.time.  TimeFilter is flagged as being allocation free but java.time is anything but that. Almost every method creates a new immutable object.  I tried modifying the logic to use Calendar but I cannot figure out how to make it account for the overlapping hour in the fall whereas java.time easily handles that.

As a consequence I am thinking that I will remove the garbage free annotation from the filter. All this means is that it will perform allocations once per day.

Any objections?

Ralph

> On Mar 9, 2020, at 12:12 AM, Apache <ra...@dslextreme.com> wrote:
> 
> I started testing this. It doesn’t handle daylight savings at all and some of the tests make no sense. I’m rewriting it using java.time and implementing better tests.
> 
> Ralph
> 
>> On Mar 8, 2020, at 11:19 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>> 
>> Is anyone else having problems with TimeFilterTest in core today?  I am in Arizona so we did not spring forward as we are MST all year.  I see the test is setting a timezone of America/Los Angeles.
>> 
>> Ralph
> 
> 
> 

Re: TimeFilterTest

[Apache <ra...@dslextreme.com>]

I started testing this. It doesn’t handle daylight savings at all and some of the tests make no sense. I’m rewriting it using java.time and implementing better tests.

Ralph

> On Mar 8, 2020, at 11:19 AM, Ralph Goers <ra...@dslextreme.com> wrote:
> 
> Is anyone else having problems with TimeFilterTest in core today?  I am in Arizona so we did not spring forward as we are MST all year.  I see the test is setting a timezone of America/Los Angeles.
> 
> Ralph