OK, thanks for the feedback.
Regards,
- Jeremy
------ Original Message ------
From: "Philip Race" <philip.r...@oracle.com>
To: "Jeremy Wood" <micklen...@gmail.com>;
client-libs-dev@openjdk.java.net
Sent: 2/12/2022 5:26:37 PM
Subject: Re: Area#add(Area) Optimization
I suppose this could be added but it is something an application also can
easily do for itself.
> curves = rhs.curves;
The straight reference, rather than a copy surprised me, but I suppose (I am
not familiar
with the working of the Area class) that all mutations must create a new Vector
...
-phil.
On 2/11/22 3:51 PM, Jeremy Wood wrote:
I’m working a lot with the Area class lately. Is there any interest in the
following optimization?
Area#add(Area) currently resembles:
public void add(Area rhs) {
curves = new AreaOp.AddOp().calculate(this.curves, rhs.curves);
invalidateBounds();
}
I propose replacing it with:
public void add(Area rhs) {
if (isEmpty()) {
curves = rhs.curves;
} else if (rhs.isEmpty()) {
return;
} else {
curves = new AreaOp.AddOp().calculate(this.curves, rhs.curves);
}
invalidateBounds();
}
If either operand is empty then this is effectively a null op. But the current
implementation may still take several seconds to return depending on the
complexity of the non-empty operand.
For example the following two snippets of code may have significantly different
execution times:
Area sum = new Area();
for(Shape shape : incomingShapes) {
sum.add(new Area(shape));
}
vs
Area sum = new Area(shapes.get(0));
for(int a = 1; a < incomingShapes.size(); a++) {
Shape shape = incomingShapes.get(a);
sum.add(new Area(shape));
}
And similarly we could review the other operations
(subtract/intersect/exclusiveOr/transform) for obvious potential null ops.
If I understand openjdk rules correctly: I'm not authorized to submit an
openJDK ticket. Does this interest anyone else on this list enough to submit
this as an openJDK ticket? (I'm happy to work on it if I can help.)
Regards,
- Jeremy
