[josm-dev] Jumbo Patch

[Petr Nejedly]

Gabriel Ebner napsal(a):
>> If the merging code ever gets in the way and parse all the timestamps
>> (which it used to do a month ago, hopefully got fixed by latest improvement
>> in the MergeVisitor), you'll get another Date instance.
> 
> It still did until a minute ago.  But I thought you had an optimized version
> of the merging code?

Yes, I have, but I put it off for a while as there was similar-meant change
in r478 and I haven't reviewed it yet and haven't updated my patch accordingly.

>>> By not using a reference type we could save 24 bytes here (one pointer + one
>>> header).
>> 12B only (do you count with 8B words or what?)
> 
> Yes, I'm on a 64-bit machine.
And really using 64bit JVM as well? I won't do it myself, it is waste
of memory with minimal or even negative (*) impact on performace for desktop
workloads (like JOSM is).

(*) x86_64 can improve performance by more registers (especially with the JDK1.6's
new register allocator), but you'll end up moving (typically) 30-40% more data,
as reference types become wider and there are a lot of references in java
application.

> 
>> But imagine this:
>>
>> public interface Coordinate {
>>      public double getLatitude();
>>      public double getLongitude();
>> }
>>
>> public class Node implements Coordinate {
>>      private double lat, lon;
>> }
>>
>> Of course we can afford that only because Coordinate has no logic attached,
>> otherwise we'd need to duplicate the logic in Node.
> 
> But we'd still be duplicating the same code wherever we want to store a
> coordinate, so this is only a last resort.

Sure,
public class CoorImpl implements Coordinate {
   double lat, lon;
   public CoorImpl(double lat, double lon) { this.lat = lat; this.lon = lon; }
   ...
}

and Node :
   public void setCoordinate(Coordinate coor) {...}

-- 
Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!