Ian Rogers wrote: > with recent discussion of performance an area that hits our [1] > performance is in sorting arrays of floats. The current Harmony code > that does this uses similar logic to Float.compareTo/compare. The > Harmony code first always explicitly tests for the uncommon NaN cases, > uses none raw bit conversion to an integer and what looks like an > expensive way to test for NaN, and that the raw integer values of -0.0 > and 0.0 are ordered. Perhaps someone could optimize this code or tell > me if I would be able to submit a patch (having already looked at and > submitted a similar patch to GNU Classpath) ?
While we could look for a way to make the code contribution work, perhaps you can describe the change first, and if it is easy enough for somebody to implement it in Harmony then that would remove any paper-shuffling nonsense. Regards, Tim
