[Unicode]   Common Locale Data Repository : Bug Tracking Home | Site Map | Search

CLDR Ticket #10990(accepted unknown)

Opened 4 months ago

Last modified 2 months ago

Fix synchronize (threading)

Reported by: mark Owned by: tbishop
Component: unknown Data Locale:
Phase: dvet Review:
Weeks: Data Xpath:


Noticed this code. I have a suspicion that our use of synchronization is a factor in suboptimal performance. Where we are synchronizing on too gross a level we will degrade performance.

public Level getLevel(String path) {

if (path == null) {

return Level.UNDETERMINED;

synchronized (lookup) { synchronize on the class, since the Matchers are changed during the matching process

Other options: we have some "kitchen sink" classes that could be split to reduce dependencies, and threading issues.


Change History

comment:1 Changed 3 months ago by mark

  • Owner changed from anybody to tbishop
  • Phase changed from dsub to dvet
  • Priority changed from assess to major
  • Status changed from new to accepted
  • Milestone changed from UNSCH to 34

comment:2 Changed 2 months ago by tbishop

This is my first ticket that's specifically for performance improvement. The two main sections of http://cldr.unicode.org/index/cldr-engineer/sow are Performance Improvement Goals and UI Improvement Goals. For performance, "The chief problem is that the performance degrades under higher load."

"Milestone #1: Create scaffolding so that simultaneous input from multiple vetters can be simulated by a tool that interacts with the survey tool, using the common actions specified in the goals."

"Milestone #2: Complete an analysis of the hotspots in loaded operation, and create a document of recommend tasks to address them (in priority order, based on the best ROI). The CLDR committee will then settle on a set of tasks to address the performance issues based on the recommendations"

Before tinkering with synchronization, I'd like to focus on testing: both performance testing to measure improvements, and unit testing to enable refactoring while guarding against unintended changes.

I'll study and employ the tests that already exist, and work on new tests.

Simulated simultaneous input from multiple vetters will be a key part of the new tests, ideally for this ticket 10990 as well as the overall task of performance improvement.

Last edited 2 months ago by tbishop (previous) (diff)

comment:3 Changed 2 months ago by tbishop

SurveyConsole may be a useful testing tool.

Draft of a future tools/SurveyConsole/readme-SurveyConsole.txt:

CLDR SurveyConsole - readme for the cldr/tools/SurveyConsole folder

SurveyConsole is a node.js monitoring app, and may be used as an uptime monitor.

It is a separate application from SurveyTool.

SurveyConsole and SurveyTool are not necessarily always both running at once.


Add a comment

Modify Ticket

as accepted

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.