Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

First, I get a different results for the construction with pack coming out fastest. These are the results of your benchmark (unchanged except for shortening the names) on my system:

c:\test>942747.pl Rate hash comma array packed hash 186995/s -- -27% -76% -77% comma 255572/s 37% -- -68% -69% array 789101/s 322% 209% -- -4% packed 819141/s 338% 221% 4% -- Rate comma packed hash array comma 273531/s -- -62% -70% -86% packed 714529/s 161% -- -21% -63% hash 900220/s 229% 26% -- -53% array 1925183/s 604% 169% 114% --

Now to your questions:

  1. Why is packing and returning six values slower than constructing a whole Perl AV data structure, creating each SvPV for each position, copying all the elements inside it and then returning that ? (compare the times of construct_packed with construct_array)

    Your construct_array doesn't "Perl AV data structure, creating each SvPV for each position, copying all the elements inside it".

    It simply returns a reference to the existing array that you constructed to hold the values.

    But you also construct that same array inside each of the other construct_* benchmark subs before getting to the additional bit they have to do.

    So the surprise -- on my system -- is that the pack version manages to be quicker. Even though it is only a little, it is consistent.

    Ie. construct_packed() does everything that construct_array() does, and then a little bit more, and still comes out quicker.

    This is a sure sign that you're not benchmarking what you think you are.

  2. Why is unpacking a blob of 6 values to 6 different SV structures(among which 2 SvIV and 3 SvPVNV and one SvUV ) slower than dereferencing a whole array and copying contents to 6 different scalars(the same types mentioned before) ? (compare times of access_array and access_packed)

    Again, both access_array() and access_packed() are allocating six scalars to hold the results and copying the values retrieved into them.

    But access_packed() has also to first to: a) parse the template string; b) allocate scalars (on the stack) to hold the unpacked values; c) unpack those values. How could it be quicker?

  3. Why is accessing a hash faster than just unpacking a string filled with data and accessing the contents ? (compare access_packed and access_hash)

    Again, access_packed() also has to allocate the six (actually seven, but you asked us to ignore that), scalars to hold the results. But whereas access_hash() only has to dereference a hash ref and copy the scalar; access_packed() has to: a) call a subroutine (unpack); b) parse the template; c) allocate 7 more scalars on the stack; d) assign the values extracted from the packed scalar to those stack vars; e) copy the values to the named scalars in the caller.

The bottom line is that both your benchmark and your expectations are fundamentally flawed.

Your expectations because you are imagining that pack & unpack should be doing less work, but in fact they are doing more. Accessing native arrays and hashes are "native operations", they don't require calling to a subroutine; setting up and tearing down teh stack frames for that subroutine; or parsing the templates as required by pack & unpack.

Your benchmark is flawed because you are attempting to benchmark very small operations, but ignoring the fact that all the setup required to benchmark those operations -- initialising the input arrays, calling the benchmark subroutines, constructing the scalars to hold the return values etc. -- is a) common to all the benchmarks; b) swamping the time taken to perform the bit you are trying to test.

I sympathise with the need to optimise your code, but you are going about it in the wrong way. If you'd care to post the actual code; or perhaps a cut down but working example that demonstrates the part that is taking too long, then you'd likely get some very good help in optimising it. In the not so distant past we've seen one or two orders of magnitude improvements in code posted here, that comes just from doing things slightly differently. (As opposed to major algorithmic improvements which can yield even greater savings.)


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?


In reply to Re: Data structures benchmark(pack vs. arrays vs. hashes vs. strings) by BrowserUk
in thread Data structures benchmark(pack vs. arrays vs. hashes vs. strings) by spx2

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2024-03-29 05:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found