Optimize the o^2 loop in DocumentBuilderIndexedEntity.addWorkToQueue

Description

there's a long-standing comment in the method:

//TODO with the caller loop we are in a n^2: optimize it using a HashMap for work recognition

Apparently it has a critical impact in some scenarios: this forum post mentions the algorithm "running for days" in a 1000 elements change in a single transaction.

Activity

Show:

Emmanuel Bernard November 6, 2010 at 4:53 PM

3.3 is too short for such a change

Emmanuel Bernard October 8, 2010 at 1:51 PM

Replied to the forum to see if the user is willing to pursue the patch.

Emmanuel Bernard October 8, 2010 at 1:40 PM

Hum we will need something to reproduce the issue before we start playing with "optimizations"

Fixed

Details

Assignee

Reporter

Fix versions

Priority

Created July 31, 2010 at 11:48 AM
Updated September 11, 2011 at 6:19 PM
Resolved December 8, 2010 at 11:38 AM

Flag notifications