8288979: Improve CLDRConverter run time #9243

djelinski · 2022-06-22T14:24:05Z

This PR improves the performance of deduplication done by ResourceBundleGenerator.

The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.

The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
The files generated before and after this change have the same size.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8288979: Improve CLDRConverter run time

Reviewers

Naoto Sato (@naotoj - Reviewer)
Roger Riggs (@RogerRiggs - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/9243/head:pull/9243
$ git checkout pull/9243

Update a local copy of the PR:
$ git checkout pull/9243
$ git pull https://git.openjdk.org/jdk pull/9243/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 9243

View PR using the GUI difftool:
$ git pr show -t 9243

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/9243.diff

bridgekeeper · 2022-06-22T14:24:27Z

👋 Welcome back djelinski! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2022-06-22T14:26:55Z

@djelinski The following labels will be automatically applied to this pull request:

build
core-libs
i18n

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

mlbridge · 2022-06-22T14:41:06Z

Webrevs

RogerRiggs · 2022-06-22T16:11:33Z

make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java

-                        if (Objects.isNull(newMap)) {
-                            newMap = new HashMap<>();
+            Map<String, Object> newMap = new HashMap<>(map);
+            Map<BundleEntryValue, BundleEntryValue> dedup = new HashMap<>(map.size());


LinkedHashMap could be used to retain the iteration order.
Or TreeMap if some deterministic order was desirable.

True. Which raises the question: do we need any arbitrary order? The original code used a hashmap too. It preserved the original order only when no duplicates were detected.

A stable order is useful when comparing between builds (by a human).
It also supports the goal of reproducible builds.
@naotoj What do you think?

IIUC, once this fix makes it to the repository, the build will be reproducible. Making it to be sorted is a welcome enhancement (I compare the generated bundles manually from time to time), but it may be costly so it could defy the performance improvement?

BTW, this can utilize the new HashMap.newHashMap(), although I don't think resizing would be occurring in this case.

once this fix makes it to the repository, the build will be reproducible

Yes, we always produce the same source code. Given the same order of modifications, a hashmap will produce the same iteration order.

LinkedHashMap could be used to retain the iteration order.

Just added. The input maps were always sorted in some order (they were either LinkedHashMaps or TreeMaps), and now we preserve that order.
This means a lot of changes in the generated output files now, but hopefully in the future the changes will be much easier to review.

TIL: put / putIfAbsent on an existing entry does not change the iteration order of a LinkedHashMap unless accessOrder is true.

BTW, this can utilize the new HashMap.newHashMap(), although I don't think resizing would be occurring in this case.

It may occur if there are very few duplicates. Still, the performance impact of proper sizing is minimal here.

make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java

naotoj

Thanks for the refactoring Daniel. Removing the leftover List was a bonus.

naotoj · 2022-06-22T21:45:25Z

make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java

-                        if (Objects.isNull(newMap)) {
-                            newMap = new HashMap<>();
+            Map<String, Object> newMap = new HashMap<>(map);
+            Map<BundleEntryValue, BundleEntryValue> dedup = new HashMap<>(map.size());


BTW, this can utilize the new HashMap.newHashMap(), although I don't think resizing would be occurring in this case.

RogerRiggs

LGTM

openjdk · 2022-06-23T14:11:37Z

@djelinski This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8288979: Improve CLDRConverter run time

Reviewed-by: naoto, rriggs

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 24 new commits pushed to the master branch:

740169c: 8285521: Minor improvements in java.net.URI
13cbb3a: 8289073: (fs) UnsatisfiedLinkError for sun.nio.fs.UnixCopyFile.bufferedCopy0()
b206d2d: 8289006: Cleanup from thread.hpp split
2728770: 8288589: Files.readString ignores encoding errors for UTF-16
ef17ee4: 8288515: (ch) Unnecessary use of Math.addExact() in java.nio.channels.FileLock.overlaps()
72f286a: 8287580: (se) CancelledKeyException during channel registration
b8db0c3: 6980847: (fs) Files.copy needs to be "tuned"
d579916: 8288740: Change incorrect documentation for sjavac flag
26c03c1: 8288719: [arm32] SafeFetch32 thumb interleaving causes random crashes
a802b98: 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used
... and 14 more: https://git.openjdk.org/jdk/compare/affbd72aa3dce80e2ad54ff775c6f7469f38b05b...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

djelinski · 2022-06-23T18:44:00Z

/integrate

openjdk · 2022-06-23T18:45:02Z

Going to push as commit c8cc94a.
Since your change was applied there have been 24 commits pushed to the master branch:

740169c: 8285521: Minor improvements in java.net.URI
13cbb3a: 8289073: (fs) UnsatisfiedLinkError for sun.nio.fs.UnixCopyFile.bufferedCopy0()
b206d2d: 8289006: Cleanup from thread.hpp split
2728770: 8288589: Files.readString ignores encoding errors for UTF-16
ef17ee4: 8288515: (ch) Unnecessary use of Math.addExact() in java.nio.channels.FileLock.overlaps()
72f286a: 8287580: (se) CancelledKeyException during channel registration
b8db0c3: 6980847: (fs) Files.copy needs to be "tuned"
d579916: 8288740: Change incorrect documentation for sjavac flag
26c03c1: 8288719: [arm32] SafeFetch32 thumb interleaving causes random crashes
a802b98: 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used
... and 14 more: https://git.openjdk.org/jdk/compare/affbd72aa3dce80e2ad54ff775c6f7469f38b05b...master

Your commit was automatically rebased without conflicts.

openjdk · 2022-06-23T18:45:15Z

@djelinski Pushed as commit c8cc94a.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Speed up CLDR deduplication

c3743d1

openjdk bot changed the title ~~8288979~~ 8288979: Improve CLDRConverter run time Jun 22, 2022

openjdk bot added build build-dev@openjdk.org core-libs core-libs-dev@openjdk.org i18n i18n-dev@openjdk.org labels Jun 22, 2022

djelinski marked this pull request as ready for review June 22, 2022 14:34

openjdk bot added the rfr Pull request is ready for review label Jun 22, 2022

RogerRiggs reviewed Jun 22, 2022

View reviewed changes

Use instanceof pattern matching

6cb4772

naotoj reviewed Jun 22, 2022

View reviewed changes

Sort output

8d26e53

RogerRiggs approved these changes Jun 23, 2022

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jun 23, 2022

naotoj approved these changes Jun 23, 2022

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Jun 23, 2022

openjdk bot closed this Jun 23, 2022

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jun 23, 2022

djelinski deleted the cldr-faster-deduplication branch October 20, 2022 11:00

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

8288979: Improve CLDRConverter run time #9243

8288979: Improve CLDRConverter run time #9243

djelinski commented Jun 22, 2022 •

edited by openjdk bot

bridgekeeper bot commented Jun 22, 2022

openjdk bot commented Jun 22, 2022

mlbridge bot commented Jun 22, 2022 •

edited

RogerRiggs Jun 22, 2022

djelinski Jun 22, 2022

RogerRiggs Jun 22, 2022

naotoj Jun 22, 2022

naotoj Jun 22, 2022 •

edited

djelinski Jun 23, 2022

djelinski Jun 23, 2022

naotoj left a comment

naotoj Jun 22, 2022 •

edited

RogerRiggs left a comment

openjdk bot commented Jun 23, 2022 •

edited

djelinski commented Jun 23, 2022

openjdk bot commented Jun 23, 2022

openjdk bot commented Jun 23, 2022

8288979: Improve CLDRConverter run time #9243

8288979: Improve CLDRConverter run time #9243

Conversation

djelinski commented Jun 22, 2022 • edited by openjdk bot

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented Jun 22, 2022

openjdk bot commented Jun 22, 2022

mlbridge bot commented Jun 22, 2022 • edited

Webrevs

RogerRiggs Jun 22, 2022

Choose a reason for hiding this comment

djelinski Jun 22, 2022

Choose a reason for hiding this comment

RogerRiggs Jun 22, 2022

Choose a reason for hiding this comment

naotoj Jun 22, 2022

Choose a reason for hiding this comment

naotoj Jun 22, 2022 • edited

Choose a reason for hiding this comment

djelinski Jun 23, 2022

Choose a reason for hiding this comment

djelinski Jun 23, 2022

Choose a reason for hiding this comment

naotoj left a comment

Choose a reason for hiding this comment

naotoj Jun 22, 2022 • edited

Choose a reason for hiding this comment

RogerRiggs left a comment

Choose a reason for hiding this comment

openjdk bot commented Jun 23, 2022 • edited

djelinski commented Jun 23, 2022

openjdk bot commented Jun 23, 2022

openjdk bot commented Jun 23, 2022

djelinski commented Jun 22, 2022 •

edited by openjdk bot

mlbridge bot commented Jun 22, 2022 •

edited

naotoj Jun 22, 2022 •

edited

naotoj Jun 22, 2022 •

edited

openjdk bot commented Jun 23, 2022 •

edited