DateIntervalFormat creation is too slow

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

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.

Replying to 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.

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.

[Mp3 бесплатно]

now,<a href="http://www.newpaulsmith.com/paul-smith-shoes-c-518.html"> Paul Smith shoes</a>,<a href="http://www.newpaulsmith.com/paul-smith-sweaters-c-526.html"> paul smith clothing</a>, and<a href="http://www.newpaulsmith.com/paul-smith-sweaters-c-526.html"> paul smith swimwear</a> are beautifully crafted with brilliant attention to detail. Paul Smith socs are an unexpected element of fun to any ensemble. Collections are primarily produced in England and Italy, while the fabrics used are mainly of Italian, French and British origin.