[31785] in Perl-Users-Digest
Perl-Users Digest, Issue: 3048 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jul 28 06:09:25 2010
Date: Wed, 28 Jul 2010 03:09:08 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 28 Jul 2010 Volume: 11 Number: 3048
Today's topics:
Re: 4D hash iteration <jurgenex@hotmail.com>
Re: 4D hash iteration <jwkrahn@example.com>
Re: 4D hash iteration <hjp-usenet2@hjp.at>
Re: Confusion about the smart matching operator (Alan Curry)
Re: Confusion about the smart matching operator <ben@morrow.me.uk>
Re: Confusion about the smart matching operator <klaus03@gmail.com>
Re: Confusion about the smart matching operator <hjp-usenet2@hjp.at>
Re: FAQ 5.13 How can I open a filehandle to a string? <justin.1007@purestblue.com>
Re: Speed of reading some MB of data using qx(...) <nospam-abuse@ilyaz.org>
Re: Speed of reading some MB of data using qx(...) <nospam-abuse@ilyaz.org>
Re: Speed of reading some MB of data using qx(...) <nospam-abuse@ilyaz.org>
Re: Speed of reading some MB of data using qx(...) <hjp-usenet2@hjp.at>
XML::Simple - Processing Query <janedunnie@gmail.com>
Re: XML::Simple - Processing Query <uri@StemSystems.com>
Re: XML::Simple - Processing Query <janedunnie@gmail.com>
Re: XML::Simple - Processing Query <xhoster@gmail.com>
Re: XML::Simple - Processing Query <uri@StemSystems.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 27 Jul 2010 17:36:14 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: 4D hash iteration
Message-Id: <3muu46pu0l27ld2rsoqb3caskrek26s4m2@4ax.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>On 2010-07-27 14:33, Jürgen Exner <jurgenex@hotmail.com> wrote:
>> Michael <a@a.com> wrote:
>>>foreach $a(...)
>>>{
>>> foreach $b(...)
>>> {
>>> foreach $c(...)
>>> {
>>> foreach $d(...)
>>> {
>>> $myval=$hash{$a}{$b}{$c}{$d};
>>> ...
>>> }
>>> }
>>> }
>>>}
>>>
>>>How to do this? What should be in braces (...)?
>>
>> Maybe something trivial like
>>
>> keys %a
>> keys %b
>> keys %c
>> keys %d
>
>Maybe. But where do %a, %b, %c and %d come from?
Maybe from
%a = %hash
%b = $a{$a}
%c = $b{$b}
%d=$c{$c}
jue
------------------------------
Date: Tue, 27 Jul 2010 22:30:23 -0700
From: "John W. Krahn" <jwkrahn@example.com>
Subject: Re: 4D hash iteration
Message-Id: <SfP3o.45515$YX3.38393@newsfe18.iad>
Michael wrote:
> I need a construction like this:
>
> foreach $a(...)
> {
> foreach $b(...)
> {
> foreach $c(...)
> {
> foreach $d(...)
> {
> $myval=$hash{$a}{$b}{$c}{$d};
> ...
> }
> }
> }
> }
>
> How to do this? What should be in braces (...)?
foreach my $a ( values %hash ) {
foreach my $b ( values %$a ) {
foreach my $c ( values %$b ) {
foreach my $d ( values %$c ) {
$myval = $d;
}
}
}
}
John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein
------------------------------
Date: Wed, 28 Jul 2010 10:32:56 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: 4D hash iteration
Message-Id: <slrni4vqpo.je6.hjp-usenet2@hrunkner.hjp.at>
On 2010-07-28 00:36, Jürgen Exner <jurgenex@hotmail.com> wrote:
> "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>>On 2010-07-27 14:33, Jürgen Exner <jurgenex@hotmail.com> wrote:
>>> Michael <a@a.com> wrote:
>>>>foreach $a(...)
>>>>{
>>>> foreach $b(...)
>>>> {
[...]
>>>> }
>>>>}
>>>>
>>>>How to do this? What should be in braces (...)?
>>>
>>> Maybe something trivial like
>>>
>>> keys %a
>>> keys %b
>>> keys %c
>>> keys %d
>>
>>Maybe. But where do %a, %b, %c and %d come from?
>
> Maybe from
> %a = %hash
> %b = $a{$a}
> %c = $b{$b}
> %d=$c{$c}
Make that
%a = %hash
%b = %{ $a{$a} }
%c = %{ $b{$b} }
%d = %{ $c{$c} }
and it will actually work.
Please make some effort to ensure that your postings are correct and
include all the relevant information. Especially since you are extremely
literal-minded and unwilling to "read between the lines" when it comes
to other people's postings.
hp
------------------------------
Date: Tue, 27 Jul 2010 22:49:14 +0000 (UTC)
From: pacman@kosh.dhis.org (Alan Curry)
Subject: Re: Confusion about the smart matching operator
Message-Id: <i2nnpa$leb$1@speranza.aioe.org>
In article <22ba29dc-83fd-4619-b250-c1297f4d2308@m18g2000vbg.googlegroups.com>,
jl_post@hotmail.com <jl_post@hotmail.com> wrote:
>
> Hmmm... contrary to what you're saying, I tried it with @a=(1,2,3);
>and it's evaluating to true for me. Here is the sample script I used
>to test it with:
>
I'll run it exactly as presented...
>
>#!/usr/bin/perl
>use strict;
>use warnings;
>my @a = (1, 2, 3);
>use Scalar::Util qw(looks_like_number);
>if ( @a ~~ sub { looks_like_number($_[0]) } ) # prints "true"
>{
> print "true";
>}
>else
>{
> print "false"
>}
>__END__
...and the answer is "false". Meanwhile, the altered version:
>
>
> In fact, if I change the sub { } to be:
>
> sub { print "$_[0]\n" }
>
>then I see:
>
>1
>2
>3
>true
gives me "ARRAY(0x10030008)" and "true".
>
>(The "true" is there because print() is returning a true value.) So I
>have to disagree with the statement that the coderef is only called
>once, with \@a as its argument.
It must be version-dependent. My perl is the one currentl found in the last
stable Debian release:
This is perl, v5.10.0 built for powerpc-linux-gnu-thread-multi
--
Alan Curry
------------------------------
Date: Wed, 28 Jul 2010 00:16:10 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Confusion about the smart matching operator
Message-Id: <qu54i7-39a2.ln1@osiris.mauzo.dyndns.org>
Quoth pacman@kosh.dhis.org (Alan Curry):
[smartmatch]
>
> It must be version-dependent. My perl is the one currentl found in the last
> stable Debian release:
>
> This is perl, v5.10.0 built for powerpc-linux-gnu-thread-multi
Smartmatch semantics changed in several small but important ways between
5.10.0 and 5.10.1. I would highly recommend avoiding smartmatch on
5.10.0 for this reason. (I believe the intention is not to change them
again.)
Ben
------------------------------
Date: Wed, 28 Jul 2010 00:03:35 -0700 (PDT)
From: Klaus <klaus03@gmail.com>
Subject: Re: Confusion about the smart matching operator
Message-Id: <ef83966a-2f47-4cc0-9191-918f7b693a4a@t10g2000yqg.googlegroups.com>
On 24 juil, 08:38, Ilya Zakharevich <nospam-ab...@ilyaz.org> wrote:
> On 2010-07-23, jl_p...@hotmail.com <jl_p...@hotmail.com> wrote:
>
> > =A0 =A0I find this a bit counter-intuitive.
>
> There is nothing "a bit counter-intuitive" about the smart matching
> operation. =A0It is just *absolutely useless*, since there is no
> humanly-possible way to predict what it would do.
I perfectly agree.
Another feature in smart matching that is counter-intuitive/useless
where there is no humanly possible way to predict what it would do is:
the rule that if the lefthand side of a smartmatch is a number and the
righthand side is a string that *looks like a number*, then that
string is treated like a number.
First of all, it is impossible in Perl 5 (due to dualvars) to see
whether or not a variable contains a number or not.
Secondly, the rule whether or not a string looks like a number is not
straight forward:
**********************************************
use strict;
use warnings;
use 5.010;
say " 1.) 0 ~~ 0 =3D=3D> does ".( 0 ~~ 0 ? '' : 'not ')."look
like number";
say " 2.) 0 ~~ '' =3D=3D> does ".( 0 ~~ '' ? '' : 'not ')."look
like number";
say " 3.) 0 ~~ ' ' =3D=3D> does ".( 0 ~~ ' ' ? '' : 'not ')."look
like number";
say " 4.) 0 ~~ '+' =3D=3D> does ".( 0 ~~ '+' ? '' : 'not ')."look
like number";
say " 5.) 0 ~~ '-' =3D=3D> does ".( 0 ~~ '-' ? '' : 'not ')."look
like number";
say " 6.) 0 ~~ '.' =3D=3D> does ".( 0 ~~ '.' ? '' : 'not ')."look
like number";
say " 7.) 0 ~~ '0.' =3D=3D> does ".( 0 ~~ '0.' ? '' : 'not ')."look
like number";
say " 8.) 0 ~~ '0.0' =3D=3D> does ".( 0 ~~ '0.0' ? '' : 'not ')."look
like number";
say " 9.) 0 ~~ 0.0 =3D=3D> does ".( 0 ~~ 0.0 ? '' : 'not ')."look
like number";
say " 10.) 0 ~~ '0+' =3D=3D> does ".( 0 ~~ '0+' ? '' : 'not ')."look
like number";
say " 11.) 0 ~~ '+0' =3D=3D> does ".( 0 ~~ '+0' ? '' : 'not ')."look
like number";
say " 12.) 0 ~~ '0-' =3D=3D> does ".( 0 ~~ '0-' ? '' : 'not ')."look
like number";
say " 13.) 0 ~~ '-0' =3D=3D> does ".( 0 ~~ '-0' ? '' : 'not ')."look
like number";
say " 14.) 0 ~~ '0E' =3D=3D> does ".( 0 ~~ '0E' ? '' : 'not ')."look
like number";
say " 15.) 0 ~~ 'E0' =3D=3D> does ".( 0 ~~ 'E0' ? '' : 'not ')."look
like number";
say " 16.) 0 ~~ '0E0' =3D=3D> does ".( 0 ~~ '0E0' ? '' : 'not ')."look
like number";
say " 17.) 0 ~~ ' 0E0' =3D=3D> does ".( 0 ~~ ' 0E0' ? '' : 'not ')."look
like number";
say " 18.) 0 ~~ '0E0 ' =3D=3D> does ".( 0 ~~ '0E0 ' ? '' : 'not ')."look
like number";
say " 19.) 0 ~~ '0 ' =3D=3D> does ".( 0 ~~ '0 ' ? '' : 'not ')."look
like number";
say " 20.) 0 ~~ ' 0' =3D=3D> does ".( 0 ~~ ' 0' ? '' : 'not ')."look
like number";
say " 21.) 0 ~~ ' 0 ' =3D=3D> does ".( 0 ~~ ' 0 ' ? '' : 'not ')."look
like number";
say " 22.) 1 ~~ 1 =3D=3D> does ".( 1 ~~ 1 ? '' : 'not ')."look
like number";
say " 23.) 1 ~~ '' =3D=3D> does ".( 1 ~~ '' ? '' : 'not ')."look
like number";
say " 24.) 1 ~~ ' ' =3D=3D> does ".( 1 ~~ ' ' ? '' : 'not ')."look
like number";
say " 25.) 1 ~~ '+' =3D=3D> does ".( 1 ~~ '+' ? '' : 'not ')."look
like number";
say " 26.) 1 ~~ '-' =3D=3D> does ".( 1 ~~ '-' ? '' : 'not ')."look
like number";
say " 27.) 1 ~~ '.' =3D=3D> does ".( 1 ~~ '.' ? '' : 'not ')."look
like number";
say " 28.) 1 ~~ '1.' =3D=3D> does ".( 1 ~~ '1.' ? '' : 'not ')."look
like number";
say " 29.) 1 ~~ '1.0' =3D=3D> does ".( 1 ~~ '1.0' ? '' : 'not ')."look
like number";
say " 30.) 1 ~~ 1.0 =3D=3D> does ".( 1 ~~ 1.0 ? '' : 'not ')."look
like number";
say " 31.) 1 ~~ '1+' =3D=3D> does ".( 1 ~~ '1+' ? '' : 'not ')."look
like number";
say " 32.) 1 ~~ '+1' =3D=3D> does ".( 1 ~~ '+1' ? '' : 'not ')."look
like number";
say " 33.) 1 ~~ '1-' =3D=3D> does ".( 1 ~~ '1-' ? '' : 'not ')."look
like number";
say " 34.) -1 ~~ '-1' =3D=3D> does ".(-1 ~~ '-1' ? '' : 'not ')."look
like number";
say " 35.) 1 ~~ '1E' =3D=3D> does ".( 1 ~~ '1E' ? '' : 'not ')."look
like number";
say " 36.) 1 ~~ 'E0' =3D=3D> does ".( 1 ~~ 'E0' ? '' : 'not ')."look
like number";
say " 37.) 1 ~~ '1E0' =3D=3D> does ".( 1 ~~ '1E0' ? '' : 'not ')."look
like number";
say " 38.) 1 ~~ ' 1E0' =3D=3D> does ".( 1 ~~ ' 1E0' ? '' : 'not ')."look
like number";
say " 39.) 1 ~~ '1E0 ' =3D=3D> does ".( 1 ~~ '1E0 ' ? '' : 'not ')."look
like number";
say " 40.) 1 ~~ '1 ' =3D=3D> does ".( 1 ~~ '1 ' ? '' : 'not ')."look
like number";
say " 41.) 1 ~~ ' 1' =3D=3D> does ".( 1 ~~ ' 1' ? '' : 'not ')."look
like number";
say " 42.) 1 ~~ ' 1 ' =3D=3D> does ".( 1 ~~ ' 1 ' ? '' : 'not ')."look
like number";
**********************************************
the result is:
**********************************************
1.) 0 ~~ 0 =3D=3D> does look like number
2.) 0 ~~ '' =3D=3D> does not look like number
3.) 0 ~~ ' ' =3D=3D> does not look like number
4.) 0 ~~ '+' =3D=3D> does not look like number
5.) 0 ~~ '-' =3D=3D> does not look like number
6.) 0 ~~ '.' =3D=3D> does not look like number
7.) 0 ~~ '0.' =3D=3D> does look like number
8.) 0 ~~ '0.0' =3D=3D> does look like number
9.) 0 ~~ 0.0 =3D=3D> does look like number
10.) 0 ~~ '0+' =3D=3D> does not look like number
11.) 0 ~~ '+0' =3D=3D> does look like number
12.) 0 ~~ '0-' =3D=3D> does not look like number
13.) 0 ~~ '-0' =3D=3D> does look like number
14.) 0 ~~ '0E' =3D=3D> does not look like number
15.) 0 ~~ 'E0' =3D=3D> does not look like number
16.) 0 ~~ '0E0' =3D=3D> does look like number
17.) 0 ~~ ' 0E0' =3D=3D> does look like number
18.) 0 ~~ '0E0 ' =3D=3D> does look like number
19.) 0 ~~ '0 ' =3D=3D> does look like number
20.) 0 ~~ ' 0' =3D=3D> does look like number
21.) 0 ~~ ' 0 ' =3D=3D> does look like number
22.) 1 ~~ 1 =3D=3D> does look like number
23.) 1 ~~ '' =3D=3D> does not look like number
24.) 1 ~~ ' ' =3D=3D> does not look like number
25.) 1 ~~ '+' =3D=3D> does not look like number
26.) 1 ~~ '-' =3D=3D> does not look like number
27.) 1 ~~ '.' =3D=3D> does not look like number
28.) 1 ~~ '1.' =3D=3D> does look like number
29.) 1 ~~ '1.0' =3D=3D> does look like number
30.) 1 ~~ 1.0 =3D=3D> does look like number
31.) 1 ~~ '1+' =3D=3D> does not look like number
32.) 1 ~~ '+1' =3D=3D> does look like number
33.) 1 ~~ '1-' =3D=3D> does not look like number
34.) -1 ~~ '-1' =3D=3D> does look like number
35.) 1 ~~ '1E' =3D=3D> does not look like number
36.) 1 ~~ 'E0' =3D=3D> does not look like number
37.) 1 ~~ '1E0' =3D=3D> does look like number
38.) 1 ~~ ' 1E0' =3D=3D> does look like number
39.) 1 ~~ '1E0 ' =3D=3D> does look like number
40.) 1 ~~ '1 ' =3D=3D> does look like number
41.) 1 ~~ ' 1' =3D=3D> does look like number
42.) 1 ~~ ' 1 ' =3D=3D> does look like number
**********************************************
--
Klaus
------------------------------
Date: Wed, 28 Jul 2010 10:48:21 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Confusion about the smart matching operator
Message-Id: <slrni4vrml.je6.hjp-usenet2@hrunkner.hjp.at>
On 2010-07-28 07:03, Klaus <klaus03@gmail.com> wrote:
> On 24 juil, 08:38, Ilya Zakharevich <nospam-ab...@ilyaz.org> wrote:
>> On 2010-07-23, jl_p...@hotmail.com <jl_p...@hotmail.com> wrote:
>>
>> > I find this a bit counter-intuitive.
>>
>> There is nothing "a bit counter-intuitive" about the smart matching
>> operation. It is just *absolutely useless*, since there is no
>> humanly-possible way to predict what it would do.
>
> I perfectly agree.
I haven't tried to use it in anger yet (as mentioned in another posting,
I have still too many machines running 5.8.x), but from reading the docs
I tend to agree: It's way too complicated and I don't think I can
remember that stuff. It is of course possible that those rules exactly
match my intuition, but somehow I doubt it.
> Another feature in smart matching that is counter-intuitive/useless
> where there is no humanly possible way to predict what it would do is:
>
> the rule that if the lefthand side of a smartmatch is a number and the
> righthand side is a string that *looks like a number*, then that
> string is treated like a number.
>
> First of all, it is impossible in Perl 5 (due to dualvars) to see
> whether or not a variable contains a number or not.
Right.
> Secondly, the rule whether or not a string looks like a number is not
> straight forward:
What's not straightforward about that? Except maybe for leading and
trailing whitespace the results are what I expected.
hp
------------------------------
Date: Wed, 28 Jul 2010 11:04:50 +0100
From: Justin C <justin.1007@purestblue.com>
Subject: Re: FAQ 5.13 How can I open a filehandle to a string?
Message-Id: <2vb5i7-u2v.ln1@zem.masonsmusic.co.uk>
On 2010-07-27, PerlFAQ Server <brian@theperlreview.com> wrote:
> 5.13: How can I open a filehandle to a string?
>
> (contributed by Peter J. Holzer, hjp-usenet2@hjp.at)
>
> Since Perl 5.8.0 a file handle referring to a string can be created by
> calling open with a reference to that string instead of the filename.
> This file handle can then be used to read from or write to the string:
>
> open(my $fh, '>', \$string) or die "Could not open string for writing";
> print $fh "foo\n";
> print $fh "bar\n"; # $string now contains "foo\nbar\n"
>
> open(my $fh, '<', \$string) or die "Could not open string for reading";
> my $x = <$fh>; # $x now contains "foo\n"
I can see how it works, but I wonder in what circumstances one might
want to do this?
Justin.
--
Justin C, by the sea.
------------------------------
Date: Wed, 28 Jul 2010 00:50:53 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Speed of reading some MB of data using qx(...)
Message-Id: <slrni4uvnd.5p1.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-07-27, Wolfram Humann <w.c.humann@arcor.de> wrote:
> sv.c). Perl_sv_grow then needs to decide if the string's memory is
> already sufficient or really needs to grow. In the latter case,
> safesysrealloc -> Perl_safesysrealloc -> realloc is called. The
> interesting point is: how much memory does it request? The answer is:
>
> newlen += 10 * (newlen - SvCUR(sv)); /* avoid copy each time */
>
> I.e. it requests 10 times as much memory as is required for the
> current append operation. So when I loop 10000 times and each time
> append 100 chars to an initial string size of 10 million, the memory
> grows from 10.000e6 to 10.001e6 to 10.002e6 and so on 1000 times till
> it ends at 11.000e6.
Good l*rd!
The current algorithm is optimized to work in tandem with "my"
malloc(), which would round up to a certain geometric progression
anyway. So if one use as different malloc()s, one should better use
newlen += (newlen >> 4) + 10; /* avoid copy each time */
Thanks for an analysis (and report this on p5p)!
Yours,
Ilya
P.S. And the current algorithm is a disaster if you try to append a
string of length 200e6 to a short string...
------------------------------
Date: Wed, 28 Jul 2010 00:59:33 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Speed of reading some MB of data using qx(...)
Message-Id: <slrni4v07l.5p1.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-07-27, Ben Morrow <ben@morrow.me.uk> wrote:
>> By the way: I estimate the time required for each realloc to be around
>> 3 ms for 10e6 chars, growing linearly with the amount of data -- I
>> consider that a fair speed and no reason to blame win32.
>
> If you timed perl's own realloc, you would (I believe) find it does much
> better than this. AFAICS from the code, it has a fixed set of block
> sizes it actually allocates. Enlarging a block such that it doesn't go
> over the block size actually allocated is *free*, not even linear in the
> size of the block, since all it does is adjust the end marker. This is
> the logic you are expecting sv_grow to implement, but perl has decided
> that this is the allocator's responsibility.
Wrong analysis. *In this particular situation* one would find Perl's
realloc() as slow as M$'s one - but it would be called MUCH more
rarely. With my malloc(), I implemented an extra call:
malloced_size(). So on the 1st iteration, things would go similarly
to "their-malloc", and realloc() would be called - and your analysis
would apply.
But on the 2nd iteration of appending, Perl would discover the new
*really* allocated size for the string, and would update the buffer
size stored in SV. After this, for many iteractions the realloc() is
out-of-the-loop altogether.
BTW, IIRC, my malloc() does not store the "end marker" at all (unless
a debugging version is used). (The bucket size of short strings
depends only on which page of memory they belong to - well, actually,
half-page.)
Hope this helps,
Ilya
------------------------------
Date: Wed, 28 Jul 2010 01:02:21 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Speed of reading some MB of data using qx(...)
Message-Id: <slrni4v0ct.5p1.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-07-27, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> I'm pretty sure that GNU malloc doesn't round up to powers of two or
> something like that. However, the performance difference between GNU
> malloc and Perl malloc is rather small:
Yeah, right. Not more than 3 times. ;-)
> perl 5.12.1, default config, EGLIBC 2.11.2-2:
>
> 1E5 chars + 1E4 x 1E2 chars: 3.9 ms
> 1E6 chars + 1E4 x 1E2 chars: 3.8 ms
> 1E7 chars + 1E4 x 1E2 chars: 4.4 ms
>
> 1E7 chars + 1E5 x 1E1 chars: 28.4 ms
> 1E7 chars + 1E4 x 1E2 chars: 4.5 ms
> 1E7 chars + 1E3 x 1E3 chars: 2.6 ms
> 1E7 chars + 1E2 x 1E4 chars: 2.0 ms
> 1E7 chars + 1E1 x 1E5 chars: 1.9 ms
>
> 1E7 chars (pre-extend to 2E7) + 1E4 x 1E2 chars: 2.0 ms
> 1E7 (1E5 x 1E2 chars) array + 1E4 x 1E2 chars : 4.4 ms
>
> perl 5.12.1, usemymalloc=y, EGLIBC 2.11.2-2:
>
> 1E5 chars + 1E4 x 1E2 chars: 2.6 ms
> 1E6 chars + 1E4 x 1E2 chars: 3.8 ms
> 1E7 chars + 1E4 x 1E2 chars: 2.5 ms
>
> 1E7 chars + 1E5 x 1E1 chars: 18.8 ms
> 1E7 chars + 1E4 x 1E2 chars: 2.5 ms
> 1E7 chars + 1E3 x 1E3 chars: 0.9 ms
> 1E7 chars + 1E2 x 1E4 chars: 0.9 ms
> 1E7 chars + 1E1 x 1E5 chars: 1.1 ms
>
> 1E7 chars (pre-extend to 2E7) + 1E4 x 1E2 chars: 1.9 ms
> 1E7 (1E5 x 1E2 chars) array + 1E4 x 1E2 chars : 3.4 ms
Yours,
Ilya
------------------------------
Date: Wed, 28 Jul 2010 10:15:22 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Speed of reading some MB of data using qx(...)
Message-Id: <slrni4vpoq.je6.hjp-usenet2@hrunkner.hjp.at>
On 2010-07-28 01:02, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> On 2010-07-27, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>> I'm pretty sure that GNU malloc doesn't round up to powers of two or
>> something like that. However, the performance difference between GNU
>> malloc and Perl malloc is rather small:
>
> Yeah, right. Not more than 3 times. ;-)
Compared to the factor of about 1000 that Wolfram and Ben observed this
is small. More importantly, growing a string to length n in constant
increments appears to be an O(n) operation with both your malloc and GNU
malloc, but O(n²) with Win32 malloc and BSD malloc.
Your malloc is certainly faster than GNU malloc. OTOH, AFAICS from
quickly scanning the comments in malloc.c, it always pads allocation to
the next power of two (minus 4) and it doesn't return unused memory back
to the OS. So it might use quite a bit more memory. Which of these
effects is more important depends on the program and is hard to
determine analytically. Which means that I should benchmark some of my
more performance-critical scripts with both allocators ;-).
hp
------------------------------
Date: Tue, 27 Jul 2010 17:42:11 -0700 (PDT)
From: "Jane D." <janedunnie@gmail.com>
Subject: XML::Simple - Processing Query
Message-Id: <35a1a47a-821a-4a81-ba1e-1845f82b8072@d37g2000yqm.googlegroups.com>
Hi,
If somebody can assist me with my query it would be much appreciated.
I'm basically retrieving an XML file from Digg. I can retrieve the
Digg data okay, but am struggling with trying to process the returned
data with Perl, largely on account with my unfamiliarity with XML
processing, but also because I'm not entirely confident with handling
arrays like this. Here's a stripped down version of the main bit of
code:
my $xml = new XML::Simple;
my $data = $xml->XMLin("$diggdata",ForceArray=>1);
foreach my $record (@{$data->{stories}->[0]->{story}})
{
print $record->{title}->[0]->{content};
print $record->{description}->[0]->{content};
# etc, etc, etc
}
The top bit of the XML file looks like this:
<?xml version="1.0" encoding="UTF-8" ?>
- <stories count="10" offset="0" timestamp="1280259772" total="137"
version="1.0">
- <story link="http://www....net/..." submit_date="1280235019"
diggs="1" id="22914259">
<description>Description of story ...</description>
<title>Story title in here</title>
<user icon="/users/eprnetwork/l.png" profileviews="12780"
registered="1170875777" />
<topic name="World News" short_name="world_news" />
<container name="World & Business" short_name="world_business" />
<shorturl short_url="http://digg.com/d31Y92p" view_count="0" />
</story>
- <story link="http://www..." submit_date="1252351084" diggs="2"
id="15603146">
<description>Story 2 description</description>
etc, etc
My issue is that I simply cannot seem to access the data in my loop,
which it does once and then exits (when it should be doing it for each
story). I also tried with ForceArray=0, but same issue. However, the
data in $diggdata is definitely there.
Additionally, I really need to know how to access the attributes of
the XML as well; for example, how to get the "link" attribute, or the
"id" attribute of the <story> tags.
Any help would be much appreciated.
Thanks.
------------------------------
Date: Tue, 27 Jul 2010 20:51:56 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: XML::Simple - Processing Query
Message-Id: <87y6cw5syb.fsf@quad.sysarch.com>
>>>>> "JD" == Jane D <janedunnie@gmail.com> writes:
JD> my $xml = new XML::Simple;
JD> my $data = $xml->XMLin("$diggdata",ForceArray=>1);
useless use of quotes on the file name.
JD> foreach my $record (@{$data->{stories}->[0]->{story}})
JD> {
JD> print $record->{title}->[0]->{content};
JD> print $record->{description}->[0]->{content};
JD> # etc, etc, etc
JD> }
JD> The top bit of the XML file looks like this:
showing xml data is useless here. use Data::Dumper to see what perl data
you got back from XML::Simple. then you can delve into that with the
proper perl array/hash accessor code.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 27 Jul 2010 18:09:52 -0700 (PDT)
From: "Jane D." <janedunnie@gmail.com>
Subject: Re: XML::Simple - Processing Query
Message-Id: <c65a43f5-8578-4f68-8c2f-9c2f561b1d9b@t2g2000yqe.googlegroups.com>
Yes, but I still need to understand how to process it. I've used
Data::Dumper to see what the data lokos like; I simply don't quite
understand how to access it.
Yes, I've looked in the help files, etc, etc ...
I just need somebody to show me how to do it, if anybody can spare a
few minutes. If not, then I guess I'll head elsewhere.
On Jul 27, 8:51=A0pm, "Uri Guttman" <u...@StemSystems.com> wrote:
> >>>>> "JD" =3D=3D Jane D <janedun...@gmail.com> writes:
>
> =A0 JD> my $xml =3D new XML::Simple;
> =A0 JD> my $data =3D $xml->XMLin("$diggdata",ForceArray=3D>1);
>
> useless use of quotes on the file name.
>
> =A0 JD> foreach my $record (@{$data->{stories}->[0]->{story}})
> =A0 JD> {
> =A0 JD> print $record->{title}->[0]->{content};
> =A0 JD> print $record->{description}->[0]->{content};
> =A0 JD> # etc, etc, etc
> =A0 JD> }
>
> =A0 JD> The top bit of the XML file looks like this:
>
> showing xml data is useless here. use Data::Dumper to see what perl data
> you got back from XML::Simple. then you can delve into that with the
> proper perl array/hash accessor code.
>
> uri
>
> --
> Uri Guttman =A0------ =A0u...@stemsystems.com =A0-------- =A0http://www.s=
ysarch.com--
> ----- =A0Perl Code Review , Architecture, Development, Training, Support =
------
> --------- =A0Gourmet Hot Cocoa Mix =A0---- =A0http://bestfriendscocoa.com=
---------
------------------------------
Date: Tue, 27 Jul 2010 20:01:21 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: XML::Simple - Processing Query
Message-Id: <4c4f9d48$0$2173$ed362ca5@nr5-q3a.newsreader.com>
Jane D. wrote:
> Yes, but I still need to understand how to process it.
If you posted "it", we could help you with that.
> I've used
> Data::Dumper to see what the data lokos like; I simply don't quite
> understand how to access it.
But we would understand, if you showed us it.
Xho
------------------------------
Date: Tue, 27 Jul 2010 23:37:35 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: XML::Simple - Processing Query
Message-Id: <87tynk2s5c.fsf@quad.sysarch.com>
if you read from top to bottom, you should post that way too.
JD> On Jul 27, 8:51 pm, "Uri Guttman" <u...@StemSystems.com> wrote:
>>
>> showing xml data is useless here. use Data::Dumper to see what perl data
>> you got back from XML::Simple. then you can delve into that with the
>> proper perl array/hash accessor code.
>>
>>>>> "JD" == Jane D <janedunnie@gmail.com> writes:
JD> Yes, but I still need to understand how to process it. I've used
JD> Data::Dumper to see what the data lokos like; I simply don't quite
JD> understand how to access it.
did you post the dumper data here? why not? i said the xml data is
useless since it is parsed into perl. the perl data is useful. we can't
help you since we can't see the perl data!!
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3048
***************************************
