Changeset 18794 in josm for trunk/src/org/openstreetmap/josm/data/conflict

Timestamp:

2023-08-07T21:10:16+02:00 (9 months ago)

Author:

taylor.smock

Message:

Fix #23085: Improve speed of selecting large amounts of objects

• JVM CPU usage was down ~50%, EDT CPU usage was down ~25%. EDT memory usage was down
• Avoid Stream allocations in ConflictCollection.hasConflictForMy by only looking for a conflict if conflicts exist
• Avoid many string instantiations in DefaultNameFormatter by using cached properties. This significantly reduces memory allocations CPU usage for DefaultNameFormatter methods.
• Avoid some Stream allocations by using standard for loops in DefaultNameFormatter
• Use "" to get the component in PrimitiveRenderer.getListCellRendererComponent -- this reduced the memory allocations by ~50% and CPU usage by ~70% for getListCellRendererComponent by itself, and appears to have no side-effects. We should ask users on different systems with different UI systems if it works properly.
• Significantly reduce cost of Way.hasOnlyLocatableNodes by using a standard for loop instead of a stream -- this isn't as important for this ticket, but was found while profiling. This makes that method have no effective memory allocations and reduces the CPU usage by ~90%.

File:

• trunk/src/org/openstreetmap/josm/data/conflict/ConflictCollection.java (modified) (2 diffs)

trunk/src/org/openstreetmap/josm/data/conflict/ConflictCollection.java

@@ -146 +146 @@
      */
     public Conflict<?> getConflictForMy(OsmPrimitive my) {
+        if (conflicts.isEmpty()) {
+            return null;
+        }
         return conflicts.stream()
                 .filter(c -> c.isMatchingMy(my))
@@ -161 +164 @@
      */
     public Conflict<?> getConflictForTheir(OsmPrimitive their) {
+        if (conflicts.isEmpty()) {
+            return null;
+        }
         return conflicts.stream()
                 .filter(c -> c.isMatchingTheir(their))