WanMil wrote
>
> * Can you please add some javadoc to the new methods? I know the old
> methods often do not have javadocs but that shouldn't be continued...
>
I totally agree. The attached correction contains comments. I am a little
bit in trouble with this because the new methods and the corr
Hello Steve,
Steve Ratcliffe wrote
>
>> What is causing mkgmap to produce different results each time when it
>> executes? This makes optimization very difficult because one cannot
>> simply
>> compare old and new result.
>
> I don't know why this happens now, and it really shouldn't (apart fro
Hi Gerd
On 12/27/2011 09:35 AM, GerdP wrote:
> I also have one question:
> What is causing mkgmap to produce different results each time when it
> executes? This makes optimization very difficult because one cannot simply
> compare old and new result.
I don't know why this happens now, and it re
On 12/27/2011 01:49 PM, GerdP wrote:
>> I don't know why this happens now, and it really shouldn't (apart from
>> > the timestamps which are easy to ignore), I will try to find out why.
>> >
> thanks, tt would be great if this could be changed.
I discovered that it is only boundary lines that are
Hello Steve,
Steve Ratcliffe wrote
>
> On 12/27/2011 01:49 PM, GerdP wrote:
>>> I don't know why this happens now, and it really shouldn't (apart from
>>> > the timestamps which are easy to ignore), I will try to find out why.
>>> >
>> thanks, tt would be great if this could be changed.
>
> I
Hi Gerd
> your fix helps when I use max-jobs=1, only a few bytes are different then,
> but I still get random output with max-jobs> 1. Is this expected?
No its not expected. In fact it appears to happen even for max-jobs=1
when you compile the same file twice on the same run. I will try to
tra
Hello Steve,
> > your fix helps when I use max-jobs=1, only a few bytes are different then,
> > but I still get random output with max-jobs> 1. Is this expected?
>
> No its not expected. In fact it appears to happen even for max-jobs=1
> when you compile the same file twice on the same run. I
Hi
> > No its not expected. In fact it appears to happen even for max-jobs=1
> > when you compile the same file twice on the same run. I will try to
> > track that down too.
>
> okay, thanks. Is this related to IdentityHashMaps ?
Well I've found it. Don't know why it took so long as it was exa
> Hi
>
>> > No its not expected. In fact it appears to happen even for max-jobs=1
>> > when you compile the same file twice on the same run. I will try to
>> > track that down too.
>>
>> okay, thanks. Is this related to IdentityHashMaps ?
>
> Well I've found it. Don't know why it took so l
Hi
> Maybe it's possible to seperate the id ranges of the FakeIdGenerator?
> Example:
> startId = 1L<< 62 + (tile no - starting with 0) * (1L<< 62 / noOfTiles)
>
> But that would require that all calls to the FakeIdGenerator are no
> longer static (or they must use the ThreadLocal object?).
Tha
Hello Steve,
yes, that works fine, thanks a lot!
Together with the proposed changes regarding the "new Date()" parts mkgmap
now creates identical output for identical input, which helps a lot when
trying performance patches. Attached is the patch that I use for this.
http://gis.638310.n2.nabble.
Hi Gerd,
>
> WanMil wrote
>>
>> * Can you please add some javadoc to the new methods? I know the old
>> methods often do not have javadocs but that shouldn't be continued...
>>
> I totally agree. The attached correction contains comments. I am a little
> bit in trouble with this because the new me
Hi WanMil,
> >
> > WanMil wrote
> >>
> >> * Can you please add some javadoc to the new methods? I know the old
> >> methods often do not have javadocs but that shouldn't be continued...
> >>
> > I totally agree. The attached correction contains comments. I am a little
> > bit in trouble with t
Hi
> reg. "local information": I totally agree, but I found no better way,
> and it saved a lot of time on my system.
Personally I think that the way you have done it in the patch is much
more natural than the existing way!
It is also possible to make the Coord structure smaller, since only 24
Hello Steve,
Steve Ratcliffe wrote
>
>> reg. "local information": I totally agree, but I found no better way,
>> and it saved a lot of time on my system.
>
> Personally I think that the way you have done it in the patch is much
> more natural than the existing way!
>
Ok, so than the patch is
Hello Steve,
I tried the "compressed" Coord class. As expected, it requires only 16 Bytes
for each instance of Coord instead of 24 bytes, but the performance
improvement is small, because the frequently called method getLongitude() is
now more complex, so we save a few cycles in GC and add some in
Am 02.01.2012 13:16, schrieb GerdP:
> Hello Steve,
>
>
>
>
> Steve Ratcliffe wrote
>>
>>> reg. "local information": I totally agree, but I found no better way,
>>> and it saved a lot of time on my system.
>>
>> Personally I think that the way you have done it in the patch is much
>> more natural th
17 matches
Mail list logo
