[mkgmap-dev] [PATCH V3]mkgmap performance

Mon Jan 2 19:47:11 GMT 2012

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 than the existing way!
>>
> Ok, so than the patch is fine for me as well.
>
>
>> It is also possible to make the Coord structure smaller, since only 24
>> bits of the latitude and longitude fields are used, so both of the
>> byte values could be located in the un-used 16 bits. Also there are
>> only three values of highwayCount that matter: 0, 1, and
>> more-than-one, so only two bits are required for that. I originally
>> did it that way, but because of a mistake I gave up and went back to a
>> separate field.  This would save a bit of memory, but it is only worth
>> doing if it results in a significant improvement in performance.
>>
> I also thought about this, but I wasn't sure how many bits are really used,
> and I got the feeling that such bitmask tricks are somehow outaged. I think
> I'll give it a try.
> I see two ways:
> 1) Keep the Coord class, but place these bits somewhere in the two interger
> fields
> 2) Use a long and map all fields in some mapping routines. This will be more
> complex, but could allow to use arrays (long[]) to store coords, and I guess
> this would mean>  50% memory saving for Coords.
>
> Gerd
>

Thanks for trying the modification. The reason why I insisted a bit on 
how the reduce the memory footprint is the coastlinefile option. Using 
this option often requires a lot of memory because the complete 
coastlines of a big area must be loaded into mkgmap at once. Reducing 
the memory footprint of the Coord objects should reduce the required 
memory a lot in this case.

But I don't think that the somehow cryptic changes are worthy. So I am 
fine with your original patch.

WanMil