[Patch] MapCSS sorting speed

[michael2402]

I experimented with the sorting speed of MapCSS.

This is what I got on 8 cores for the big MapCSS performance test:

• Current implementation: 116ms
• Using parallel sort instead of default sort: 40ms
• Removing the branches for the comparator function: 53ms
• Both: 28ms

The disadvantage of the branch removal is that I changed the z-index to be a fixed-point decimal (24 bits of which 8 are behind the decimal). This allows to pack the Z-Indexes and the flags into a long that can then be compared more easily.

If there are no objections to this rescriction I'd like to commit it.

[bastiK]

Replying to michael2402:

The disadvantage of the branch removal is that I changed the z-index to be a fixed-point decimal (24 bits of which 8 are behind the decimal).

So in decimal terms, the maximum z-index is 65535 and it should not have more than 2 digits after the decimal point? Sounds okay to me.

[michael2402]

In 12054/josm:

Fix #14485: Increase sorting speed by removing compareTo complexity.

[bastiK]

Unit tests are failing.

[stoecker]

Causes following warnings:

    [javac] /var/lib/jenkins/jobs/JOSM-Integration/workspace/jdk/JDK8/src/org/openstreetmap/josm/data/osm/visitor/paint/StyledMapRenderer.java:146: warning: [OperatorPrecedence] Use grouping parenthesis to make the operator precedence explicit
    [javac]             long highestBitMask = 1L << totalBits - 1;
    [javac]                                                   ^
    [javac]     (see http://errorprone.info/bugpattern/OperatorPrecedence)
    [javac]   Did you mean 'long highestBitMask = 1L << (totalBits - 1);'?
    [javac] /var/lib/jenkins/jobs/JOSM-Integration/workspace/jdk/JDK8/src/org/openstreetmap/josm/data/osm/visitor/paint/StyledMapRenderer.java:149: warning: [OperatorPrecedence] Use grouping parenthesis to make the operator precedence explicit
    [javac]             return signBit | value & valueMask;

The second seems correct and should obviously be "signBit | (value &valueMask)". Should the first really be "1L << (totalBits - 1)? Please add the correct brackets.

[michael2402]

In 12078/josm:

See #14485: Fix and test MapCSS sorting.

This adds support for real floating point values instead of fixed point decimal and tests for corner cases (infinity, nan, ...)

[bastiK]

Could you please document the limitations?

Btw., it wouldn't be a problem to loose one or two bits in the exponent, e.g. ​S/360 floats have only 7 bits in the exponent.

[michael2402]

In 12208/josm:

See #14485: Fix order of disabled style elements

[Klumbumbus]

So are there limitations in use of z-index, object-z-index and major-z-index after r12054 and r12078?

[michael2402]

Yes. We do not support 32 bit floats but only 24 bit floats.

You should not notice a much of difference unless your are using z-index values with more than 4 decimal digits - which may only happen when using complex computations.

If you encounter any issues with shorter z-indexes, there is a bug somewhere ;-)

[Klumbumbus]

So what exactly is the range that can be used? Can you please document at Help/Styles/MapCSSImplementation?

[michael2402]

How exact should the documentation be? As far as I know, MapCSS has no real requirements on floating point values since there is no real spec for it.

The numeric range is approx -3.4 * 10³⁸ ... 3.4 * 10³⁸, with a precision of ~5 decimal digits. So having 1.0001 and 1.0002 should be fine, and having 10001 and 10002 should be fine as well ;-).

There are many other limitations on floating point values we have (e.g. numbers are not allowed to start with a '.'). I don't think we can document them all - if we would do that we could as well write a real MapCSS specification with exact grammar and so on and then state our differences.

[Klumbumbus]

I added the docu, please correct it if it is wrong:
https://josm.openstreetmap.de/wiki/Help/Styles/MapCSSImplementation?action=diff&version=144