How to handle large variable

[Uri Guttman]

AJ> No, you didn't state that, and I didn't get that from your post at
AJ> all. Did I state that you did? I made it clear (or I tried to) that I
AJ> too consider it important to let things be well defined. How do you
AJ> get from "would like to see" to "thinks we need"?

AJ> Is there a need to rub it in? We agree. I'm the kind of person who'd
AJ> like to see a formal definition for Perl.

in that paragraph you said you agree and then commented on a formal
definition. that reads to me like i said that too and you agree. see,
ambiguous english! to what did you agree? that is dangling (at least in
my eyes .

AJ> I'll look up the names you mention - apart from that I don't see
AJ> how your answer relates to my question, even if I agree (if I'm
AJ> permitted to do so) with what you write.

well, those are two very good writers and excellent perl writers in
particular. so their books will improve your perl and show you ways to
write high quality technical english.

uri

 

[Ben Morrow]

Exactly how vague is one allowed to be without misleading, when saying
things about 'undef', I wonder. "$x has no value", "$x is undefined",
"$x has the value 'undef'", "$x has the undefined value", "$x is set
to nothing". Which of these are OK? I haven't picked up the common
Perl speech patterns yet.

I would say (though I'm no authority) that '$x is undefined', '$x is
undef' or '$x has the undefined value' are all unambiguous, with the
seconed being preferred for brevity. '$x has no value' may be OK in some
contexts, but (e.g.) in the context of hash members it would be unclear
whether you mean

exists($x) and !defined($x)

or

!exists($x)

'$x is undefined' can be confusing also: for instance (to take an
example from another thread) I would be tempted to say that in

my $x if $y;

'$x is undefined' if $y is false; here I would *NOT* mean '$x = undef'
but rather that $x might be *anything*, undef or otherwise... so
probably best avoid that one, too.

Ben

 

[Tad McClellan]

Exactly how vague is one allowed to be without misleading, when saying
things about 'undef', I wonder.

As vague as you like *without introducing an ambiguity*.

"$x has no value",

That one is just plain incorrect.

It _does_ have a value, the "special" value named "undef".

"$x is undefined",
"$x has the value 'undef'", "$x has the undefined value",

Those all seem fine to me.

"$x is set
to nothing".

There are 3 kinds of "nothing" with regards to a Perl scalar.

It might be zero, or it might be the empty string, or it might
be undef (which can act like either a zero or an empty string
depending on how you use it).

With regards to $/, you get "slurp mode" with undef and "para mode"
with the empty string, so it really does make a difference here.

 

[ctcgag]

c> In my hands, not much. I found it marginally slower than the old
c> fashioned way.

care to show some benchmarks?

Sorry, I can't. I cleaned them out a few weeks ago when I get tired of
trying to guess which filename, test1.pl, test2.pl, test3.pl, etc. was
currently available for overwriting. Anyway, I had a program which read
and processed 50,000 files. I just commented out the processing step, then
ran it with and without the File::Slurp code, alternating a few times.
Slurp was consistently slower by a negligible amount.

have you looked at the benchmark script
that comes in the tarball?

Not until just now. I just use-d it and perldoc-ed, I usually don't dig
into tarballs except in extreme circumstances. I looked it now, though,
and it looked OK but not great, except for list slurp of Long file, which
looked aweful:

List Slurp of LONG file
new_array_ref
41.3/s new 44.0/s
new_in_anon_array 44.4/s
cpan_read_file 253/s
cpan_slurp_to_array 257/s
cpan_slurp_to_array_ref 383/s
read_file 383/s
sysread_file 387/s

But that doesn't seem right, because me benchmark would have definitley not
been as close as it was if "new" was that much worse than the old fashioned
way.

and was that for line/record mode or scalar
mode? return by ref or by value?

It must have been line/record to match the program I threw it into.
Also, I guess it must have been value, because I just copied the code
out whatever post it was that prompted me to do the test, and all the
posts I can find just use the value way.

just saying it is slower is like newbies saying it doesn't work

Well, if you need to invoke some special option to get a performance
advantage, I'd think gushing posts would give example code with that
option already invoked.

I'm not saying no one should use it or anything, but it just didn't blow my
hair back, as the saying goes.

Xho

 

[Uri Guttman]

c> looked aweful:

c> List Slurp of LONG file
c> new_array_ref
c> 41.3/s new 44.0/s
c> new_in_anon_array 44.4/s
c> cpan_read_file 253/s
c> cpan_slurp_to_array 257/s
c> cpan_slurp_to_array_ref 383/s
c> read_file 383/s
c> sysread_file 387/s

c> But that doesn't seem right, because me benchmark would have
c> definitley not been as close as it was if "new" was that much worse
c> than the old fashioned way.

i will have to take a look at that. also the latest version has a change
to allow paragraph mode and it uses a m// instead of a split so the
benchmarks have possibly changed.

c> It must have been line/record to match the program I threw it into.
c> Also, I guess it must have been value, because I just copied the code
c> out whatever post it was that prompted me to do the test, and all the
c> posts I can find just use the value way.

when slurping a list of lines, most of the time is spent splitting up
the lines vs reading in the file. so file::slurp gains the least in that
mode. but IMO it does have a cleaner api than the normal open/list
slurp/close methods.

c> Well, if you need to invoke some special option to get a
c> performance advantage, I'd think gushing posts would give example
c> code with that option already invoked.

not much to gush over here. it is faster in almost all cases, it has a
cleaner and easier to use api and it has many options to control i/o and
error handling.

c> I'm not saying no one should use it or anything, but it just didn't
c> blow my hair back, as the saying goes.

well, as i said, list slurping is slower in all solutions. use it for
the better api then.

uri