[GLASSFISH-401] Vector processing is sub-optimal Created: 14/Mar/06
Updated:
12/Mar/15 Resolved: 24/Mar/06
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Resolved
glassfish
entity-persistence
9.0pe
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Environment:
Bug
Scott Oaks
Fixed
None
Not Specified
Attachments:
bug.jar
401
Issuezilla Id:
9.0pe
Priority:
Assignee:
Votes:
Major
tware
0
Not Specified
Not Specified
Operating System: All
Platform: All
Description
I've been looking at some profiles of the performance test, and one of
the bottlenecks occurs because of this code in ObjectBuilder.java:
public void iterate(DescriptorIterator iterator) {
// PERF: Avoid synchronized enumerator as is concurrency bottleneck.
Vector mappings = getDescriptor().getMappings();
for (int index = 0; index < mappings.size(); index++)
{ ((DatabaseMapping)mappings.get(index)).iterate(iterator); }
}
Similar code exists in
DefferredChangeDetectonPolicy.createObjectChangeSetThroughComparison(),
DatabaseAccessor.fetchRow(), ObjectBuilder.buildAttributesIntoObject(),
and AbtractRecord.getIndicatingNoEntry().
As these vectors are immutable, the size() call should be removed out of the for
loop to reduce significant contention on the vector's lock. Long term, the code
should be migrated to use arrays (a simple approach would be to extend the
Vector class and override the toArray() method to return the same immutable
array on all calls – that would allows badly-performing sections to be changed
to use arrays without refactoring the entire codebase).
Comments
Comment by Scott Oaks [ 22/Mar/06 ]
Created an attachment (id=164)
Test case
Comment by Scott Oaks [ 22/Mar/06 ]
Sorry; I meant to attach this test case to a different bug, but I don't see any
way to delete it from this bug. Please ignore the test case.
Comment by guypelletier [ 23/Mar/06 ]
Changes made in next persistence drop.
Comment by tware [ 24/Mar/06 ]
Fixed in latest drop
Comment by marina vatkina [ 24/Mar/06 ]
Added build #
Generated at Wed Feb 10 00:38:13 UTC 2016 using JIRA 6.2.3#6260sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.