[mkgmap-dev] FW: AW: RE: computing power mdx/mdr

Thu Feb 26 11:41:22 GMT 2015

Hi Steve,

your patch (which BTW contains a lot of experimental code) tries to avoid
the additional memory for the MultiSortKey. That is probably also a good
idea in case the compareTo() routines can handle
different types properly.

My idea was to optimize the cases where partial name and name are different.
If I got it right, we use this to handle the highway shields. 
I wonder if it would be enough to move the byte(s) for the highway shield
to the end of the name that is used for sorting?

Gerd

Steve Ratcliffe wrote
> On 25/02/15 15:45, GerdP wrote:
>> I think a better solution reg. memory would be not to store the
>> byte array for the partial name at all. Since it is a sub string of
>> the name, I assume it should be sufficient to calc the offset and length
>> in the byte array and store these values?
> 
> Where do you mean? A call to substring() shares the byte array of the 
> original string, so there is no extra array.  Also I don't think it
> is stored anywhere as the sort key is a new array.
> 
> We just do not need the MultiSortKey when the partialName is the same as 
> the name so we can eliminate using the partialName
> altogether.
> 
> As in attached patch (warning: untested).
> 
> ..Steve
> 
> _______________________________________________
> mkgmap-dev mailing list

> mkgmap-dev at .org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> single-key-for-full-name.patch (3K)
> &lt;http://gis.19327.n5.nabble.com/attachment/5835052/0/single-key-for-full-name.patch&gt;

--
View this message in context: http://gis.19327.n5.nabble.com/FW-AW-RE-computing-power-mdx-mdr-tp5834885p5835055.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.