Details
-
Improvement
-
Status: In Progress
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
On a partitioned region put benchmark (with redundancy), I noticed that AbstractUpdateOperation.doPutOrCreate calls basicUpdate twice. The first time is to see if it can be a create. If it is then it is done. But in the case of an update this first call "fails" and we then call basicUpdate again this time telling it to do an update instead of a create.
It seems like this code could be optimized. In my benchmark most of the puts are updates. In that case I see the first call to basicUpdate accounting for 3% of all the object allocations. These are all garbage and end up being done again when we call basicUpdate the second time. In addition to these allocations, that first call also takes some amount of cpu. I think the first calls gets all the way down to having the entry synced and then figures out it exists and "fails" since it is not a create.
Attachments
Issue Links
- links to
