http://qs1969.pair.com?node_id=942757


in reply to Re^3: Data structures benchmark(pack vs. arrays vs. hashes vs. strings)
in thread Data structures benchmark(pack vs. arrays vs. hashes vs. strings)

this is correct. however, writing each time $AoA->[ $thingToProcess ][ something ] could lead to hard to understand code.

also, if in the benchmarks, I use every time the "copying the subarrays to local named scalars" , these cancel themselves out, so basically the benchmark is still valid from this point of view, do you agree ?

  • Comment on Re^4: Data structures benchmark(pack vs. arrays vs. hashes vs. strings)
  • Download Code

Replies are listed 'Best First'.
Re^5: Data structures benchmark(pack vs. arrays vs. hashes vs. strings)
by BrowserUk (Patriarch) on Dec 10, 2011 at 01:41 UTC
    also, if in the benchmarks, I use every time the "copying the subarrays to local named scalars" , these cancel themselves out, so basically the benchmark is still valid from this point of view, do you agree ?

    Not really, no. The problem is you have equations something like:

    (call_time=1000) + (allocate_names=150) + (copy_values=250) + (extra_b +it_a=15) versus (call_time=1000) + (allocate_names=150) + (copy_values=250) + (the_ext +ra_bit=5)

    The extra bit is so small relative to the set-up and tear-down, you cannot accurately instrument the differences you are interested in. They just get mixed up in the noise of the overheads

    this is correct. however, writing each time $AoA->[ $thingToProcess ][ something ] could lead to hard to understand code.

    I sympathise with this. In this case I would construct the code differently. Instead of calling the subroutines as:

    sub process { my( $AoA, $thingToProcess ) = @_; $AoA->[ $thingToProcess ][ 3 ] = $AoA->[ $thingToProcess ][ 1 ] * $AoA->[ $thingToProcess ][ 2 ]; ... return; } ... process( $AoA, 123 );

    Do it this way:

    ## Use meaningful names obviously!! use constant { 0 => FIRST, 1 => SECOND, 2 => THIRD, 3 => FOURTH, 4 => FIFTH, 5 => SIXTH, 6 => SEVENTH }; sub process( our @s; local *s = shift; $s[ FOURTH ] = $s[ SECOND ] + $s[ THIRD ]; ... return; } process( $AoA[ $thingToProcess ] );

    The first (our) line allows us to use the global variable locally.

    The second line (local) aliases a local copy of the global variable to the sub array within the external @AoA

    The use constant gives us meaningful names for the subarray elements.

    The effect is direct, in-situ access to the subarrays without the need to copy and via short, meaningful names.

    • Aliasing is a very cheap operation -- just a pointer assigned.
    • All data copying is avoided.
    • Short, meaningful names.
    • Constants are resolved at compile time making access very fast.

      Real constants that is! Don't be fooled by the crass, laborious & slow, oxymoronic poor substitutes of "ReadOnly variables".

    The results is clean, safe and very readable and maintainable code that is also efficient.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    The start of some sanity?