Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re^3: selecting columns from a tab-separated-values file

by BrowserUk (Pope)
on Jan 22, 2013 at 17:15 UTC ( #1014738=note: print w/ replies, xml ) Need Help??


in reply to Re^2: selecting columns from a tab-separated-values file
in thread selecting columns from a tab-separated-values file

taking care that I/O doesnít sneak up on you from the backside in the form of virtual-memory paging.

You and your hobby horses. Virtual memory limits don't enter into it.

When running, those two programs I posted use 2.7 MB and 3.2 MB respectively when using the 256 times larger read size than standard that I suggest. Even if I increase that 10-fold to 10MB each -- which slows the processing down -- they use a whole 12 MB & 16 MB. The programmer that runs my heating system could handle that.

Iím personally not sure that threads would help here

I'm not sure that standing on one leg whilst drinking blood from a freshly decapitated chicken would help; so I don;t mention it.

And your instincts prejudiced guessing is wrong!

Approximately 2/3rds of the throughput gains from my posted solution come exactly because the CPU intensive part of the processing -- the spliting and joining of the records -- can run flat out (100% utilisation) on one CPU, whilst the first thread doing the Input is instantly ready to respond to the completion of each read because it isn't having to perform any CPU intensive processing on each record.

push it onto an array (of hashrefs).

The input is a stream; the output is a stream; What on earth do you need an array of hashrefs for?

I suspect that you will be astonished at what just-this does for the program.

No. I can pretty much call it without trying it. It will run 3 to 5 times slower than a simple:

perl -F"\t" -anle"print join chr(9), @F[2,0,5]" in.tsv > out.tsv

That is, instead of taking the OPs 5+ hours to run it will take closer to 24 hours.

Why? You'll never know unless you try it. And you won't do that.

(And even if you get someone else to do it for you, you won't post the results, because it will show your 'advice' to be nothing more than groundless guessing.)


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.


Comment on Re^3: selecting columns from a tab-separated-values file
Download Code
Re^4: selecting columns from a tab-separated-values file
by sundialsvc4 (Abbot) on Jan 22, 2013 at 21:16 UTC

    Bah, humbug ...   ;-)

    There’s one million-pound elephant in this room, if there is one at all, and that elephant certainly won’t consist of the mere-microseconds that a CPU will require to split-up a chunk of data that came in from a disk drive.   We’re not reading graphic-images here and resizing them ... the task to be performed against each unit of data is quite inconsequential.   The advantage comes from being able to gulp large amounts of data at a time from a disk device that (probably ...) does not have to spend too much time dong it.   (Although, depending on the peculiarities of physical distribution of the file-in-question across the disk real estate, that might not turn out to be so.)

    “What is the array of hashrefs for?”   Why, you yourself said it!   Even though “the input is a stream, and the output is a stream,” there is probably only one device.   A physical operation consisting of seek + read or seek + write, which we desire to reduce to the point that no seek is required.   We want:   seek($$) + read + read + read + ... + read + seek($$) + write + write .... + write + seek ($$).

    The specific reason why I questioned the validity of threads in this scenario, was that I judged the amount of CPU-intensive processing required to be pragmatically inconsequential relative to the amount of time that would be spent in an I/O-wait.   Also, it was because I judged that the physical latency cost of the disk device would be the “above all, ruling constraint” no matter what.   Pragmatically, we can afford to spend a few microseconds crunching numbers because the disk platter won’t have rotated too far during that time anyway.

    But there is only so far that the point can be argued before it becomes merely an argument.   If the per-record CPU load is indeed slight to the point of being inconsequential, then memory is a big fat available buffer that costs nothing ... if, indeed paging is not occurring, so that it really does cost “nothing.”   But if a page-fault that must be resolved to disk does take place, then you just moved that read/write head after all.   Overlapping I/O with CPU-processing might prove to be beneficial on the OP’s system, not yours... or not.   If it were me, I would start by using the RAM as a buffer, see how much bang that buck got me, then pragmatically move forward from there.

    It doesn’t advance the technical validity of your arguments to belittle the opinions others, you know... no matter how personally self-assured you might be.

      It doesnít advance the technical validity of your arguments to belittle the opinions others, you know... no matter how personally self-assured you might be.

      I am not belittleing your opinion. There is no matter of opinion involved. This is not a subjective matter; it is a quantifiable, easily measured, matter of right and wrong; fact and fiction. And you provided fiction, whilst I provided fact.

      I am telling directly and definitively and unambiguously, that the technical content -- such as it is -- in both your first post and this one are both theoretically -- and demonstrably -- factually incorrect. Ie. You are wrong!


      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1014738]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (9)
As of 2014-09-23 19:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (241 votes), past polls