icu4c 63.1 date format is significantly slower as compared to icu4c 56.


We have been using icu 56. Just upgraded to icu 63 and found that it is almost taking double time in smaller performance tests of our application.

For larger runs time is 50% increased.

Mostly it is date formatting but we observed UnicodeString constructor is also taking more time.


Shane Carr
February 27, 2019, 6:57 PM

I worked on this part of the code in

I was able to get the .format() method on SimpleDateFormat to actually improve performance between 61 and 62. However, this came at the expense of the constructor. The performance regression only happens if you "create and destroy" a SimpleDateFormat.

Jeff Genovy
February 27, 2019, 7:01 PM

Thanks Shane!

That's a good point. The sample code provided was creating and destroying the SimpleDateFormat object repeatedly in a loop.

If you could hoist the creation of the object outside of any loops, then the performance would likely improve.

Muhammad Owais
February 28, 2019, 9:50 AM

We did that for SimpleDateFormat. I modified this test application to use only UnicodeString and performed find and concatenation.
ICU61 performed better than ICU63. In next test I just increased the operations and did not create any new object of UnicodeString. ICU63 performed better here.

So constructor of UnicodeString is also taking extra time in ICU63. This in unavoidable.

Shane Carr
February 28, 2019, 11:12 AM

If the UnicodeString constructor is slow, you might be performing a charset conversion. Can you change the lines that read

to instead read

with the u"" syntax, and see if that improves the performance?

Jeff Genovy
June 9, 2020, 6:50 PM

Unassigned as this a general performance issue and isn’t specifically related to Visual Studio.




Muhammad Owais








Time Needed


Fix versions