develooper Front page | perl.perl5.porters | Postings from March 2014

February 2014 optimisation work report

Thread Next
From:
Dave Mitchell
Date:
March 12, 2014 14:42
Subject:
February 2014 optimisation work report
Message ID:
20140312144158.GP12844@iabyn.com
For anyone who's interested, here's a copy of the report I wrote for
Booking.com regarding my optimisation work in the last month.

  * avoid creating xhv_aux struct with keys% h, values %h, @a = %h

        The extra fields in a HV that aren't needed for simple hashes
        (such as objects rather than stashes), are stored in the HvAUX()
        structure which is allocated at the end of HvARRAY(). However, it
        turns out that a simple 'keys %h', 'values %h', or '@a = %h'
        instantiates HvAUX.

        I have a fully worked-up patch which avoids instantiating HvAUX in
        this case, but it ran into a snag due to the randomisation of hash
        iteration. Specifically in the following:

            @a = keys %h;
            for (my ($k,$v) = each %h) { ... }

        perl guarantees that the order of keys in @a is the same as
        iterated by each. Since the iterator perturbator (xhv_rand) is
        stored in HvAUX(), it doesn't get created until we execute each,
        which then does things in a different order from keys.

        I discussed this back and forth privately with Yves quite a lot,
        and we came up with some ideas for storing xhv_rand in the same
        field as xhv_keys and/or xhv_max, but this is something to be
        addressed after 5.20. Once that's done, my original patch (or
        variant) can then be included.

  * dereferencing overloaded objects

        Fully merged into blead. Dereferencing overloaded objects (like
        $obj->{foo}) is no longer slow.

  * investigate overhead of my_perl arg

        I wondered that, since on x86_64, args to a function are passed in
        registers, could the my_perl arg on threaded builds just be kept
        in the same register as its passed between functions? Perhaps by
        declaring the parameter as const, in conjunction with a compiler
        option maybe? After a bit of research, decided it wasn't feasible:
        gcc wont use the const-ness of a function parameter to conclude
        that it doesn't need to save and restore the value.

  * make aelemfast use range -128..127 not 0..255

        Now in blead. A small but nice optimisation.

  * skip OP_NULLs

        This was the start of the work which was concluded in the
        following month, of avoiding pp_null() being called at runtime.
        Currently smoking.

  * tweak SAVEt_CLEARSV/SAVEt_CLEARPADRANGE

        Now in blead. This hot part of the leave_scope() function
        now has smaller object code (97 bytes less) and skips a lot of
        tests for "simple" lexical vars.

  * tweak pp_entersub

        Now in blead. The common code paths of this hot function have
        been tweaked, and LIKELY()s scattered around, and reduces the
        object size of the function by 11%.

-- 
Overhead, without any fuss, the stars were going out.
    -- Arthur C Clarke

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About