[29843] in Perl-Users-Digest
Perl-Users Digest, Issue: 1086 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Dec 1 21:09:45 2007
Date: Sat, 1 Dec 2007 18:09:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 1 Dec 2007 Volume: 11 Number: 1086
Today's topics:
ActiveState Perl 5.10 under Windows XP dilbert1999@gmail.com
Re: ActiveState Perl 5.10 under Windows XP <bik.mido@tiscalinet.it>
Re: ActiveState Perl 5.10 under Windows XP <ben@morrow.me.uk>
Re: Email with text file attachment <rkb@i.frys.com>
Re: Email with text file attachment <m@rtij.nl.invlalid>
Re: Error using SMTP object. <pgmrdan@hotmail.com>
Re: OT raibow <1usa@llenroc.ude.invalid>
Re: OT raibow <hjp-usenet2@hjp.at>
Re: OT raibow <m@rtij.nl.invlalid>
Re: OT raibow <sbryce@scottbryce.com>
Re: OT raibow <nospam-abuse@ilyaz.org>
Re: OT raibow <joost@zeekat.nl>
Re: Perl and a Ramdisk <nospam@somewhere.com>
Re: Perl and a Ramdisk <ben@morrow.me.uk>
Re: Perl and a Ramdisk <m@rtij.nl.invlalid>
Re: Sorted Hash <a1ddaad2-89c6-4b01-bd39-2e27e36ffe39@b <hjp-usenet2@hjp.at>
Re: Sorted Hash <a1ddaad2-89c6-4b01-bd39-2e27e36ffe39@b <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 1 Dec 2007 09:16:28 -0800 (PST)
From: dilbert1999@gmail.com
Subject: ActiveState Perl 5.10 under Windows XP
Message-Id: <f6224a2e-2a17-4944-b3ae-d7209b3e5f2e@r60g2000hsc.googlegroups.com>
Hi all,
I have used Perl 5.8.8 for some time now, but I hope you don't mind if
I post my first ever perl 5.10 program and ask for comments: (I just
discovered that ActiveState have now released a Beta for Perl 5.10
under Windows XP)
C:\>perl -v
This is perl, v5.10.0 built for MSWin32-x86-multi-thread
(with 2 registered patches, see perl -V for more detail)
Copyright 1987-2007, Larry Wall
Binary build 1000 [283192] Beta provided by ActiveState http://www.ActiveState.com
Built Nov 22 2007 14:37:48
Here is my program :
use strict;
use warnings;
use feature ':5.10';
property($_) for (0, 1, 2, 3, 4, 'aad', 'abd', 'acd', 'add', 99, 100,
101, 3.1415);
sub property {
my $foo = shift;
printf 'my $foo = %-10s -- ', $foo;
given ($foo) {
when (1) { say "\$foo == 1" }
when ([2,3]) { say "\$foo == 2 || \$foo == 3" }
when (/^a[bc]d$/) { say "\$foo eq 'abd' || \$foo eq 'acd'" }
when ($_ > 100) { say "\$foo > 100" }
default { say "None of the above" }
}
}
Any comments ?
------------------------------
Date: Sat, 01 Dec 2007 19:00:12 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: ActiveState Perl 5.10 under Windows XP
Message-Id: <c583l3dksda3vqtgekbto24c0bq3ocaqjr@4ax.com>
On Sat, 1 Dec 2007 09:16:28 -0800 (PST), dilbert1999@gmail.com wrote:
>Here is my program :
>
>use strict;
>use warnings;
>use feature ':5.10';
>
>property($_) for (0, 1, 2, 3, 4, 'aad', 'abd', 'acd', 'add', 99, 100,
>101, 3.1415);
>
>sub property {
> my $foo = shift;
> printf 'my $foo = %-10s -- ', $foo;
> given ($foo) {
> when (1) { say "\$foo == 1" }
> when ([2,3]) { say "\$foo == 2 || \$foo == 3" }
> when (/^a[bc]d$/) { say "\$foo eq 'abd' || \$foo eq 'acd'" }
> when ($_ > 100) { say "\$foo > 100" }
> default { say "None of the above" }
> }
>}
>
>Any comments ?
It doesn't seem to have anything Windows or FWIW ActivePerl specific.
Other than that, cool.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 1 Dec 2007 22:42:16 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: ActiveState Perl 5.10 under Windows XP
Message-Id: <8j4925-gsk1.ln1@osiris.mauzo.dyndns.org>
Quoth dilbert1999@gmail.com:
> Hi all,
>
> I have used Perl 5.8.8 for some time now, but I hope you don't mind if
> I post my first ever perl 5.10 program and ask for comments: (I just
> discovered that ActiveState have now released a Beta for Perl 5.10
> under Windows XP)
>
> Here is my program :
>
> use strict;
> use warnings;
> use feature ':5.10';
>
> property($_) for (0, 1, 2, 3, 4, 'aad', 'abd', 'acd', 'add', 99, 100,
> 101, 3.1415);
>
> sub property {
> my $foo = shift;
For extra added 5.10-ness I might make that (totally untested)
property for (...);
sub property (_) {
my $foo = shift;
The new _ prototype character causes an argument to default to $_. :)
> printf 'my $foo = %-10s -- ', $foo;
> given ($foo) {
> when (1) { say "\$foo == 1" }
> when ([2,3]) { say "\$foo == 2 || \$foo == 3" }
> when (/^a[bc]d$/) { say "\$foo eq 'abd' || \$foo eq 'acd'" }
> when ($_ > 100) { say "\$foo > 100" }
> default { say "None of the above" }
Mmmm, /me likes. I can see given/when coming in very useful...
Ben
------------------------------
Date: Sat, 1 Dec 2007 09:25:54 -0800 (PST)
From: Ron Bergin <rkb@i.frys.com>
Subject: Re: Email with text file attachment
Message-Id: <a82d6f00-cd81-4757-9da0-3cadabe4750a@d21g2000prf.googlegroups.com>
On Dec 1, 3:57 am, Martijn Lievaart <m...@rtij.nl.invlalid> wrote:
> On Fri, 30 Nov 2007 20:30:41 -0800, Ron Bergin wrote:
> > This is not the method I'd use, because I'd be using MIME::Lite, but you
> > could do a system call to uuencode (to encode your file attachment) and
> > pass it to the mail command.
>
> I've used this method often and it works like a charm.
>
> M4
Yes, it does work, but it's not as flexible and it unnecessarily
spawns additional processes. This method of sending an email is not
"not very Perlish"; it's most often done in shell scripts. So, do you
want to write a shell script or perl script?
------------------------------
Date: Sat, 1 Dec 2007 21:50:42 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Email with text file attachment
Message-Id: <pan.2007.12.01.20.50.42@rtij.nl.invlalid>
On Sat, 01 Dec 2007 09:25:54 -0800, Ron Bergin wrote:
> On Dec 1, 3:57 am, Martijn Lievaart <m...@rtij.nl.invlalid> wrote:
>> On Fri, 30 Nov 2007 20:30:41 -0800, Ron Bergin wrote:
>> > This is not the method I'd use, because I'd be using MIME::Lite, but
>> > you could do a system call to uuencode (to encode your file
>> > attachment) and pass it to the mail command.
>>
>> I've used this method often and it works like a charm.
>>
>> M4
>
> Yes, it does work, but it's not as flexible and it unnecessarily spawns
> additional processes. This method of sending an email is not "not very
> Perlish"; it's most often done in shell scripts. So, do you want to
> write a shell script or perl script?
Sometimes I want to write a script that works without installing
additional modules. In medical environments it is simpler to get one
script validated than a script plus installing new modules.
Besides, Perl is a very good glue language, often better suited than the
shell. So yes, maybe I just want to write a shell script and do it in
Perl.
M4
------------------------------
Date: Sat, 1 Dec 2007 19:16:37 -0600
From: "pgmrdan" <pgmrdan@hotmail.com>
Subject: Re: Error using SMTP object.
Message-Id: <fit0l2$g7h$1@news.netins.net>
Good point! Thank you.
"Martijn Lievaart" <m@rtij.nl.invlalid> wrote in message
news:pan.2007.12.01.11.57.02@rtij.nl.invlalid...
> On Fri, 30 Nov 2007 19:41:05 -0600, pgmrdan wrote:
>
> > Never mind. I had the wrong SMTP server name. It works now.
>
> Yes, but....
>
> > "pgmrdan" <pgmrdan@hotmail.com> wrote in message
> > news:fiqb57$83p$1@news.netins.net...
> >> I'm getting the following message -
> >>
> >> Can't call method "domain" on an undefined value at domain.pl line 4.
> >>
> >> When trying to execute the following -
> >>
> >> use Net::SMTP;
> >>
> >> $smtp = Net::SMTP->new('xxxxxxxxxx.xxx');
>
> You never test for success here.
>
> $smtp = Net::SMTP->new('xxxxxxxxxx.xxx') or die "<insert suitable
> message>";
>
> >> print $smtp->domain,"\n";
> >> $smtp->quit;
>
> HTH,
> M4
------------------------------
Date: Sat, 01 Dec 2007 16:20:51 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: OT raibow
Message-Id: <Xns99F9736DCB4F1asu1cornelledu@127.0.0.1>
"Petr Vileta" <stoupa@practisoft.cz> wrote in
news:fipin5$vsd$1@ns.felk.cvut.cz:
> My question is not perl specific but here are many clever people :-)
You don't see me asking for restaurant recommendations here, do you?
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines: <URL:http://www.augustmail.com/~tadmc/clpmisc.shtml>
------------------------------
Date: Sat, 1 Dec 2007 23:01:25 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: OT raibow
Message-Id: <slrnfl3mdl.k4i.hjp-usenet2@zeno.hjp.at>
On 2007-12-01 03:37, Petr Vileta <stoupa@practisoft.cz> wrote:
> Joost Diepenmaat wrote:
>> On Fri, 30 Nov 2007 18:39:35 +0100, Petr Vileta wrote:
>>
>>> I want to generate html <select> object with all "safe" colors but in
>>> rainbow order (from white over yellow, red upt to black). I want to
>>> use hexadecimal values for RGB but only 0,33,66,99,cc and ff values.
>>> Please know anybody some algorithm how to do it?
>>
>> A rainbow contains just the "unmixed" colors in the visible spectrum
>> so it does not contain white or black and also misses a few other
>> colors: http://en.wikipedia.org/wiki/Visible_spectrum
>>
>> If that's not a problem, see:
>> http://www.philiplaven.com/p19.html
>> http://www.midnightkite.com/color.html
>>
>> Joost.
> Thank you Joost, but my problem is a bit different. Not all internet user can
> see thousands or milions colors on display (e.g. on mobile phone), but most
> people can see 256 color. In addition to this fe years ago somebody define set
> of colors called "safe colors".
Quite a bad name. These colors were never "safe" in the sense that the
inventor intended. It assumes that on a system with 256 colors there are
less than 40 colors already in use - but that's not guaranteed, and if
there are less than 216 colors "free" browsers resort to a smaller cube
with totally different colors. So forget the "safe" colors and use the
colors you want and make sure that there is enough contrast between
colors you want to distinguish even if the display can only approximate
them.
> I'm looking for some algorithm what generate the same table but more similar
> to rainbow.
Convert from RGB to HSV then sort by H.
hp
--
_ | Peter J. Holzer | It took a genius to create [TeX],
|_|_) | Sysadmin WSR | and it takes a genius to maintain it.
| | | hjp@hjp.at | That's not engineering, that's art.
__/ | http://www.hjp.at/ | -- David Kastrup in comp.text.tex
------------------------------
Date: Sat, 1 Dec 2007 23:16:33 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: OT raibow
Message-Id: <pan.2007.12.01.22.16.33@rtij.nl.invlalid>
On Sat, 01 Dec 2007 16:20:51 +0000, A. Sinan Unur wrote:
> "Petr Vileta" <stoupa@practisoft.cz> wrote in
> news:fipin5$vsd$1@ns.felk.cvut.cz:
>
>> My question is not perl specific but here are many clever people :-)
>
> You don't see me asking for restaurant recommendations here, do you?
Ah, but you don't need clever people for restaurant recommendations, now
do you? :-)
[ Don't get me wrong, the question /is/ OT. ]
M4
------------------------------
Date: Sat, 01 Dec 2007 16:18:52 -0700
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: OT raibow
Message-Id: <JNCdnc3EKvZ2dszanZ2dnUVZ_hadnZ2d@comcast.com>
Peter J. Holzer wrote:
> Convert from RGB to HSV then sort by H.
This might help.
http://search.cpan.org/~aizvorski/Graphics-ColorObject-0.5.0/ColorObject.pm
------------------------------
Date: Sun, 2 Dec 2007 00:35:53 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: OT raibow
Message-Id: <fisul9$3hl$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Joost Diepenmaat
<joost@zeekat.nl>], who wrote in article <4750698f$0$18641$e4fe514c@dreader28.news.xs4all.nl>:
> A rainbow contains just the "unmixed" colors in the visible spectrum so
A rainbow contains VERY mixed colors. It's a wonder that these colors
are distinguishable by eye at all; they are very low saturation (even
if the background is very dark - which it usually is not).
[Very OT:] assuming ideally spherical form of water droplets, it
should not be hard to calculate position of rainbow colors
on the color triangle; have anyone seen this "published"?
Thanks,
Ilya
------------------------------
Date: 02 Dec 2007 01:00:24 GMT
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: OT raibow
Message-Id: <475203a8$0$20387$e4fe514c@dreader32.news.xs4all.nl>
On Sun, 02 Dec 2007 00:35:53 +0000, Ilya Zakharevich wrote:
> A rainbow contains VERY mixed colors. It's a wonder that these colors
> are distinguishable by eye at all; they are very low saturation (even if
> the background is very dark - which it usually is not).
Getting further and further off-topic.
I am under the impression that a rainbow contains/is a "frequency sweep"
of visible light, which would mean that the colors aren't mixed - at
every point you'd have light of a single frequency.
The way the human eye actually processes light means visible light is
processed as a mixture of stimuli to the 3 types of cone cells, but
looking at the wiki page*, it seems that all colours except the ones at
the far ends of the spectrum are detected by at least 2 of the 3 types of
cell.
If you mean that real-life rainbows are mixed with light from all kinds
of other sources, and don't just contain a plain spectrum, I agree.
* http://en.wikipedia.org/wiki/Color_vision
Joost.
------------------------------
Date: Sat, 1 Dec 2007 18:14:44 -0500
From: "Thrill5" <nospam@somewhere.com>
Subject: Re: Perl and a Ramdisk
Message-Id: <0MydnZ9yRJZ4d8zanZ2dnUVZ_hOdnZ2d@comcast.com>
"Bill H" <bill@ts1000.us> wrote in message
news:e3791e7a-4d6d-4d98-9a14-3c2acdbb23fd@g30g2000hsb.googlegroups.com...
> On Nov 30, 1:12 pm, smallpond <smallp...@juno.com> wrote:
>> On Nov 30, 12:46 pm, Bill H <b...@ts1000.us> wrote:
>>
>> > I am working on a chat program and am thinking of using a ramdisk to
>> > hold the chat data. Is there anything special I should know about
>> > accessing ramdisk from perl or is it just another disk to perl? On my
>> > development machine I don't have a ramdisk, so I will be using the HD
>> > for storing while debuging, but on the machine it will run on there is
>> > one, and it would be nice if I could just have a variable holding the
>> > destination and only have to change that instead of changing any
>> > routines that did any file i/o.
>>
>> > Bill H
>>
>> "Premature optimization is the root of all evil."
>> -- C. A. R. Hoare
>>
>> Your plan is good right up to the part where you actually
>> switch over to using the ramdisk. Every modern OS already
>> has excellent code to do secure and reliable caching of disk
>> data. I would see if the disk access is actually a problem
>> before changing, which should be just the filename that you
>> open or a symbolic link.
>>
>> If you do create a ramdisk, you will need to create a
>> filesystem in it, unless you plan on using the raw disk.
>> You will also have to preload it and worry about saving
>> it on shutdown if it will contain any permanent data.
>> --S
>
> I am not concerned about loosing the data with shutdown, since it is
> chat the data is transient, only need what someone types for a few
> seconds to echo it to the other chatters. I am more concerned with
> speed and less disk accesses. I figure it will be a whole lot faster
> open a file, reading, writing, closing files in a ramdisk than in on a
> HD.
>
> Bill H
I agree, before using a RAMDISK, why not see if using a files on a disk is a
problem? You have created a solution in search of a problem and definitely
putting the cart before the horse. Creating, opening, reading and writing
small files on a RAMDISK is not going to be that much faster than using a
real disk because the amount of data you are reading and writing is small.
Any modern OS is going to cache the data anyway, so in effect you are
already reading and writing to a RAMDISK. If your program does run slow,
using a RAMDISK will not increase performance dramatically because every
process will need to open, read and then close the file. A better solution
would be to use shared memory, which is very efficient, and much faster than
using files to store temporary data needed by multiple processes. There are
several CPAN modules that implement shared memory.
------------------------------
Date: Sat, 1 Dec 2007 23:43:30 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl and a Ramdisk
Message-Id: <268925-g5l1.ln1@osiris.mauzo.dyndns.org>
Quoth "Thrill5" <nospam@somewhere.com>:
>
> I agree, before using a RAMDISK, why not see if using a files on a disk is a
> problem? You have created a solution in search of a problem and definitely
> putting the cart before the horse. Creating, opening, reading and writing
> small files on a RAMDISK is not going to be that much faster than using a
> real disk because the amount of data you are reading and writing is small.
> Any modern OS is going to cache the data anyway, so in effect you are
> already reading and writing to a RAMDISK.
Since we are talking about files that change often, every byte written
will have to get flushed to disk at some point. If there is a real disk
involved that means lots of IO, however clever the kernel caching is.
> If your program does run slow, using a RAMDISK will not increase
> performance dramatically because every process will need to open, read
> and then close the file. A better solution would be to use shared
> memory, which is very efficient, and much faster than using files to
> store temporary data needed by multiple processes. There are several
> CPAN modules that implement shared memory.
At least Linux implements both SysV and POSIX shared memory as mmaped
files from a ramdisk. (The ramdisk used for SysV shm is private to the
kernel and doesn't need mounting in userspace, but it is effectively a
mount of tmpfs.)
Ben
------------------------------
Date: Sun, 2 Dec 2007 01:16:05 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Perl and a Ramdisk
Message-Id: <pan.2007.12.02.00.16.05@rtij.nl.invlalid>
On Sat, 01 Dec 2007 23:43:30 +0000, Ben Morrow wrote:
> Quoth "Thrill5" <nospam@somewhere.com>:
>>
>> I agree, before using a RAMDISK, why not see if using a files on a disk
>> is a problem? You have created a solution in search of a problem and
>> definitely putting the cart before the horse. Creating, opening,
>> reading and writing small files on a RAMDISK is not going to be that
>> much faster than using a real disk because the amount of data you are
>> reading and writing is small. Any modern OS is going to cache the data
>> anyway, so in effect you are already reading and writing to a RAMDISK.
>
> Since we are talking about files that change often, every byte written
> will have to get flushed to disk at some point. If there is a real disk
> involved that means lots of IO, however clever the kernel caching is.
Try it. Yes, a ramdisk may be faster, but by how much? Modern OSses are
so intelligent in handling disk I/O I doubt you'll see any difference in
practice.
And yes, I'm talking experience here. Under MSDOS, yes, a well placed
ramdisk made all the difference. Switching to NT and Linux anything I
assigned to a ramdisk became unavailable to the system for diskcaching,
making overall performance a lot worse. But given enough memory disk
caching is so efficient a ramdisk is not noticeably more efficient than a
temporary file on disk.
Also, I've seen a lot of big iron. I've managed a web server and ftp
server that on a certain day every year are the most visited Internet
servers in the Netherlands. Not the same use case but we managed a lot of
servers there. Not one used a ramdisk, just because there was no
performance to be gained. Just let the OS sort it out, monitor it, and
when it runs out of memory, add more memory.
By all means try it. I'll be very surprised if a ramdisk gives you any
real performance benefits.
HTH,
M4
------------------------------
Date: Sat, 1 Dec 2007 22:29:30 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Sorted Hash <a1ddaad2-89c6-4b01-bd39-2e27e36ffe39@b40g2000prf.googlegroups.com> <Xns99F7CDC51277Fasu1cornelledu@127.0.0.1>
Message-Id: <slrnfl3khq.k4i.hjp-usenet2@zeno.hjp.at>
On 2007-11-30 01:13, A. Sinan Unur <1usa@llenroc.ude.invalid> wrote:
> "palexvs@gmail.com" <palexvs@gmail.com> wrote in news:a1ddaad2-89c6-4b01-
> bd39-2e27e36ffe39@b40g2000prf.googlegroups.com:
>> I filled hash and then printed it (sorted by key):
>> my %hs = (
>> key10 => 5,
>> key5 => b,
>> aey9 => 7,
>> )
>> foreach my $k (sort keys %hs) { print "$k $hs{$k}\n"; }
>>
>> key - string ([0-9A-F]{72}), 50K records.
>> How do it more effective?
>
> Well, depends on what you mean by 'more effective'.
>
> If you are talking about speed, note that the only place where you can
> really get any meaningful improvement is IO.
I don't see anything in your post supporting that claim. So lets try it:
print "$_ $hash{$_}\n" for sort keys %hash; 0.217 s
print "$_ $hash{$_}\n" for keys %hash; 0.112 s
(on a 1.86 GHz Core 2 running Linux, writing to a disk file. Writing to
/dev/null is about 0.02 seconds faster)
The unsorted version is almost twice as fast as the sorted version. So
eliminating or improving the sort has about the same potential as
improving I/O. In fact, the second number includes the time for walking
through the hash, which is unavoidable, so the I/O takes less than 50 %
of the total time, making the sort the prime candidate for optimization.
So how could the sort be sped up or eliminated?
Tie::IxHash keeps the hash sorted, but has quite a lot of overhead. On
my machine printing the hash takes about 0.465 seconds, which is worse
than sorting the keys on demand.
Another way would be to use a faster sort method, as Salvador suggested.
Finally, if you either need to print the hash several times or fill it
in sorted order you could just keep the sorted keys around instead of
sorting every time.
hp
--
_ | Peter J. Holzer | It took a genius to create [TeX],
|_|_) | Sysadmin WSR | and it takes a genius to maintain it.
| | | hjp@hjp.at | That's not engineering, that's art.
__/ | http://www.hjp.at/ | -- David Kastrup in comp.text.tex
------------------------------
Date: Sat, 1 Dec 2007 22:49:14 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Sorted Hash <a1ddaad2-89c6-4b01-bd39-2e27e36ffe39@b40g2000prf.googlegroups.com> <Xns99F7CDC51277Fasu1cornelledu@127.0.0.1>
Message-Id: <a05925-gsk1.ln1@osiris.mauzo.dyndns.org>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>
<sorting a hash>
>
> So how could the sort be sped up or eliminated?
>
> Tie::IxHash keeps the hash sorted, but has quite a lot of overhead. On
> my machine printing the hash takes about 0.465 seconds, which is worse
> than sorting the keys on demand.
>
> Another way would be to use a faster sort method, as Salvador suggested.
>
> Finally, if you either need to print the hash several times or fill it
> in sorted order you could just keep the sorted keys around instead of
> sorting every time.
...which is what Tie::IxHash does, but you'd be avoiding the
inefficencies of tie. Yet another way would be to rewrite Tie::IxHash in
C, or use DB_File/DB_BTREE which effectively does that for you. I don't
know how much you win by having the tie methods in C: that depends on
the efficiency of perl's method cache. It is possible, though probably
not often a good idea, to use tie magic with a different vtable, and
avoid the method lookup altogether. See threads::shared for a (somewhat
incomprehensible) example.
Ben
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 1086
***************************************
