While running the DateIntervalFormatTest/testFormat test, DateIntervalFormat creation takes most of the time.

"Average time taken per iteration in testFomat is 0.005694852941176471 sec for the total 1360 iterations"

"Average time taken per iteration to create DateIntervalFormat is 0.005108088235294118 sec for the total 1360 iterations"

This can be because of the time taken by the DateTimePatternGenerator since DateIntervalFormat depends on DateTimePatternGenerator. For example, in DateTimeGeneratorTest/TestReplacingZoneString test

"Average time taken per iteration in TestReplacingZoneString test is 0.07291752577319588 sec for the total 97 iterations"

"Average time taken per iteration to create DateTimePatternGenerator is 0.019494845360824742 sec for the total 97 iterations"

Show:

TracBot

June 30, 2018, 11:51 PM

While running the DateIntervalFormatTest/testFormat test, DateIntervalFormat creation takes most of the time.

"Average time taken per iteration in testFomat is 0.005694852941176471 sec for the total 1360 iterations"

"Average time taken per iteration to create DateIntervalFormat is 0.005108088235294118 sec for the total 1360 iterations"

This can be because of the time taken by the DateTimePatternGenerator since DateIntervalFormat depends on DateTimePatternGenerator. For example, in DateTimeGeneratorTest/TestReplacingZoneString test

"Average time taken per iteration in TestReplacingZoneString test is 0.07291752577319588 sec for the total 97 iterations"

"Average time taken per iteration to create DateTimePatternGenerator is 0.019494845360824742 sec for the total 97 iterations"

Could you please let me know how did you do the measurement?

I can measure accordingly while fixing the problem.

Thanks,

Xiaomei

TracBot

June 30, 2018, 11:51 PM

One performance issue which I found was in FormatParser. The FormatParser builds a PatternTokenizer which involves several UnicodeSet instances. Because the initial state of PatternTokenizer is all same across FormatParser instances, so I tried caching the one and create a clone for each FormatParser. This change improved the DateIntervalFormat instantiation time a lot. Another big performance bottle neck would be the code building an object holding zone display names. If the object is not yet cached, it takes really long time to create one. This issue is addressed in several different tickets.

TracBot

June 30, 2018, 11:51 PM

Replying to (Comment 3 xji):

Replying to [krajwade|]:

> While running the DateIntervalFormatTest/testFormat test, DateIntervalFormat creation takes most of the time.

>

> "Average time taken per iteration in testFomat is 0.005694852941176471 sec for the total 1360 iterations"

>

> "Average time taken per iteration to create DateIntervalFormat is 0.005108088235294118 sec for the total 1360 iterations"

>

> This can be because of the time taken by the DateTimePatternGenerator since DateIntervalFormat depends on DateTimePatternGenerator. For example, in DateTimeGeneratorTest/TestReplacingZoneString test

>

> "Average time taken per iteration in TestReplacingZoneString test is 0.07291752577319588 sec for the total 97 iterations"

>

> "Average time taken per iteration to create DateTimePatternGenerator is 0.019494845360824742 sec for the total 97 iterations"

Could you please let me know how did you do the measurement?

I can measure accordingly while fixing the problem.

Thanks,

Xiaomei

In the DateIntervalFormatTest/testFormat, I measured the average time required to run one test case inside the while loop and the average time required to create DateIntervalFormat for one test case.

TracBot

June 30, 2018, 11:51 PM

I tried in DateIntervalFormat side by caching the date time pattern generator to minimize the instantiation of DateTimePatternGenerator.

While instantiating a date interval formatter, date time pattern generator **might** be needed in 2 places: in creating a date time formatter (by getPatternInstance), which is a must, and when fallback pattern is needed in date interval formatter, which is a might.

By caching, each date interval formatter will only instantiate date time pattern generator once, and it improve the performance by 35%.

Caching also minimize the date time pattern generator instantiation across different date interval formatter instantiation, which saves a lot.

The code was checked in on 09/13.

TracBot

June 30, 2018, 11:51 PM

Milestone 4.1.1 deleted