Thanks for reviewing, Roger


On 2018-02-14 17:50, Roger Riggs wrote:
Hi Claes,

Looks fine,


On 2/14/2018 11:36 AM, Claes Redestad wrote:
Right, I expanded the range as much as possible given the constraint provided by L_ENCODED minus '/'. I will think of a better comment to this effect.


Daniel Fuchs <> skrev: (14 februari 2018 17:25:20 CET)

    Hi Claes,

    Your proposed changes to ParseUtil look reasonable
    to me, though I had to carefully compare the characters
    in the range (c >= '&' && c <= ':') with the
    L_ENCODED / H_ENCODED masks to convince myself
    that there was no behavior change to

    I wonder whether this would deserve some additional
    comment - though I'm not sure how it could be formulated.

    Given the sensitivity of the impacted code maybe it would
    be prudent to wait for a second review before pushing.

    best regards,

    -- daniel

    On 14/02/2018 15:30, Claes Redestad wrote:

        Hi, as a means to improve startup in some applications, please
        review this set of small improvements to improve both
        interpreted and compiled performance of creating and handling
        certain jar URLs. Some of the changes in have a small, positive
        effect when dealing with other types of path resources. Bug: Webrev:
<> This
        shaves off a percent or so of the total bytecode execution in
        a few of our startup tests: - ParseUtil::encodePath cost is
        reduced ~20% during startup, averaging ~10-15% faster for
        typical inputs after JIT. Weird examples like paths only
        consisting of slashes and dots can be seen to take a small hit
        due to not getting special treatment. -
        ParseUtil::canonizeString cost on startup reduced by 50% (~15%
        improvement after JIT) for typical inputs by adding a test to
        return directly if there's no need to "canonize" the string
        (which is typically always the case for well-formed jar
        files). I added a sanity test to ensure I didn't accidentally
        change semantics of cases that would lead to canonicalization.
        - Removed a couple of unnecessary allocation in Maybe there are some good
        reasons not to make ParseUtil a final utility class with only
        static methods and a private constructor, though... Thanks!

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Reply via email to