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@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
single-key-for-full-name.patch (3K) <http://gis.19327.n5.nabble.com/attachment/5835052/0/single-key-for-full-name...;
-- View this message in context: http://gis.19327.n5.nabble.com/FW-AW-RE-computing-power-mdx-mdr-tp5834885p58... Sent from the Mkgmap Development mailing list archive at Nabble.com.