[32699] in Perl-Users-Digest
Perl-Users Digest, Issue: 3963 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jun 13 14:09:22 2013
Date: Thu, 13 Jun 2013 11:09:09 -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 Thu, 13 Jun 2013 Volume: 11 Number: 3963
Today's topics:
a new Tree::Interval-like module on top of Tree::RB? <oneingray@gmail.com>
Re: advice needed for color selection <hjp-usenet3@hjp.at>
Re: advice needed for color selection <hjp-usenet3@hjp.at>
Re: advice needed for color selection <nospam@lisse.NA>
Deep structure access and temp variable <adrien.barreau@live.fr>
Re: Deep structure access and temp variable <rweikusat@mssgmbh.com>
Re: Deep structure access and temp variable <ben@morrow.me.uk>
Re: Deep structure access and temp variable <jurgenex@hotmail.com>
Re: Deep structure access and temp variable <adrien.barreau@live.fr>
Re: Deep structure access and temp variable <adrien.barreau@live.fr>
Re: Deep structure access and temp variable <adrien.barreau@live.fr>
Re: Deep structure access and temp variable <jimsgibson@gmail.com>
Re: Deep structure access and temp variable <jurgenex@hotmail.com>
How to minimize server load when program is run <justin.1303@purestblue.com>
Re: How to minimize server load when program is run <rvtol+usenet@xs4all.nl>
Re: How to minimize server load when program is run <jimsgibson@gmail.com>
Re: How to minimize server load when program is run <ben@morrow.me.uk>
Re: Is there a better way than this? <m@rtij.nl.invlalid>
Re: Perfect Insider's Guide To Selling Hot Properties <jurgenex@hotmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 13 Jun 2013 17:13:28 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: a new Tree::Interval-like module on top of Tree::RB?
Message-Id: <87ip1igchz.fsf@violet.siamics.net>
So, I've crafted the base for a Tree::Interval-like module,
implemented on top of Tree::RB, and I'm open to suggestions of
what'd be a suitable name for it?
The obvious candidates are Tree::RB::Interval and
Tree::Interval::RB, but I'm uncertain if it'd be nice to
infiltrate someone's else CPAN namespace in this case.
FWIW, Tree::Interval::RB seems more appropriate, as the code as
it is requires only the compare, delete, insert and lookup
methods from the "backend," and thus could probably be not that
hard to generalize. (Although the lookup method is expected to
allow for "imprecise" matching, and then it demands a way to
iterate onwards from the node found...)
A nice feature of this code is that it relies on the tree's own
"compare" function, which could be rather arbitrary. Thus, it's
possible to, say:
my $map
= XXX->new (...);
$map->set ("from", "to", "value");
my $a
= $map->lookup ("fuzzy");
## => "value"
(provided that the tree is built around the "cmp" function.)
TIA.
--
FSF associate member #7257 np. faceday.mod
------------------------------
Date: Tue, 11 Jun 2013 21:59:34 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: advice needed for color selection
Message-Id: <slrnkrf0d6.k10.hjp-usenet3@hrunkner.hjp.at>
On 2013-06-10 11:49, Dr Eberhard Lisse <nospam@lisse.NA> wrote:
> I have a variable number of entities (from an SQL script) each of which
> I want to assign a color to so I can print them with GraphViz.
>
> How do I select the most visible colors?
>
> Ie if I have 10, 30, 57, 98, 259 entities, how do I select appropriate
> colours (dynamically, so to speak) so that they (and of course arrows
> originating from them but that is easy to do in GraphViz) become most
> visible on (white) paper?
>
> Pointers are as welcome as finished product :-)-O
Some ideas:
The perceived brightness of a color is approximately 0.3*R + 0.6*G + 0.1*B.
When printing on paper, you may want to exclude colors which are too
bright. So one idea is to generate random colors and reject those where
the brightness is above some threshold.
You probably want your colors evenly spread out. A purely random
distribution may result in some colors being very close together. So you
could apply a spring model to the colors to improve the distribution.
Or you could generate a regular 3D-Grid (with the bright area cut out)
by generating a sufficient number of regularly spaced colors and then
keeping only the darkest.
In any case you probably want to apply some gamma correction after that.
When generating colored graphs with random colors I have found it useful
to cache the colors so that the each entity keeps its color between runs
(and only new entities are assigned new colors).
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Tue, 11 Jun 2013 22:01:37 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: advice needed for color selection
Message-Id: <slrnkrf0h1.k10.hjp-usenet3@hrunkner.hjp.at>
On 2013-06-11 19:59, Peter J. Holzer <hjp-usenet3@hjp.at> wrote:
> On 2013-06-10 11:49, Dr Eberhard Lisse <nospam@lisse.NA> wrote:
>> I have a variable number of entities (from an SQL script) each of which
>> I want to assign a color to so I can print them with GraphViz.
>>
>> How do I select the most visible colors?
>>
>> Ie if I have 10, 30, 57, 98, 259 entities, how do I select appropriate
>> colours (dynamically, so to speak) so that they (and of course arrows
>> originating from them but that is easy to do in GraphViz) become most
>> visible on (white) paper?
>
> Some ideas:
Forgot to add: You may get better results by choosing a different color
space (e.g. HSV instead of RGB).
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Wed, 12 Jun 2013 09:32:37 +0100
From: Dr Eberhard Lisse <nospam@lisse.NA>
Subject: Re: advice needed for color selection
Message-Id: <51B83225.2040705@lisse.NA>
Peter,
thank you very much.
In the end I took the X11 colors by name, whittled out the bright
ones manually and put the rest in an array. I increment a counter
each time a color is used and when I reach the maximum I set it back
to zero and reuse.
That works out reasonably well :-)-O
el
on 2013-06-11 21:01 Peter J. Holzer said the following:
> On 2013-06-11 19:59, Peter J. Holzer <hjp-usenet3@hjp.at> wrote:
>> On 2013-06-10 11:49, Dr Eberhard Lisse <nospam@lisse.NA> wrote:
>>> I have a variable number of entities (from an SQL script) each
>>> of which I want to assign a color to so I can print them with
>>> GraphViz.
>>>
>>> How do I select the most visible colors?
>>>
>>> Ie if I have 10, 30, 57, 98, 259 entities, how do I select
>>> appropriate colours (dynamically, so to speak) so that they (and
>>> of course arrows originating from them but that is easy to do in
>>> GraphViz) become most visible on (white) paper?
>>
>> Some ideas:
>
> Forgot to add: You may get better results by choosing a different
> color space (e.g. HSV instead of RGB).
>
> hp
>
------------------------------
Date: Thu, 13 Jun 2013 16:55:18 +0200
From: Adrien BARREAU <adrien.barreau@live.fr>
Subject: Deep structure access and temp variable
Message-Id: <kpcm7k$ra8$1@dont-email.me>
Hi all.
A simple question, but I have no clue about it:
# Version 1
my $A = $stuff->{a}{b}{c}{d}{e};
my $B = $stuff->{a}{b}{c}{d}{f};
my $C = $stuff->{a}{b}{c}{d}{g};
# Version 2
my $tmp = $stuff->{a}{b}{c}{d};
my $A = $tmp->{e};
my $B = $tmp->{f};
my $C = $tmp->{g};
What is the most efficient?
What appears to be the most idiomatic?
I don't have the knowledge about Perl guts to properly guess here.
Of course, it does not have be only HASHes refs in the structure.
Adrien.
------------------------------
Date: Thu, 13 Jun 2013 16:18:11 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Deep structure access and temp variable
Message-Id: <87mwqurqdo.fsf@sapphire.mobileactivedefense.com>
Adrien BARREAU <adrien.barreau@live.fr> writes:
> A simple question, but I have no clue about it:
>
> # Version 1
> my $A = $stuff->{a}{b}{c}{d}{e};
> my $B = $stuff->{a}{b}{c}{d}{f};
> my $C = $stuff->{a}{b}{c}{d}{g};
>
> # Version 2
>
> my $tmp = $stuff->{a}{b}{c}{d};
> my $A = $tmp->{e};
> my $B = $tmp->{f};
> my $C = $tmp->{g};
>
>
> What is the most efficient?
This depends on the relative cost of the additional assignment versus
that of the dereferencing chain. I usually follow the rule of thumb
that using an intermediate variable only makes sense if it is going to
be used for at least three times.
But there's a more important concern: Readiblity of the code and the
ease with which it can be modified: Both suffer in case of 'obnoxious
repetition', as in your first example. Also, the intermediate variable
could have a more sensible name than $tmp which could communicate its
nature better the $stuff->{a}{b}{c}{d}.
> What appears to be the most idiomatic?
Is you're asking about "what everyone else does" you can rest assured
that no problem which can be solved with copy'n'paste will be solved
with anything but copy'n'paste because this minimizes that time of
each individual 'trivial work unit' (also, people greatly prefer
moving over thingking).
------------------------------
Date: Thu, 13 Jun 2013 16:55:36 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Deep structure access and temp variable
Message-Id: <ok6p8a-u9b2.ln1@anubis.morrow.me.uk>
Quoth Adrien BARREAU <adrien.barreau@live.fr>:
>
> A simple question, but I have no clue about it:
>
> # Version 1
> my $A = $stuff->{a}{b}{c}{d}{e};
> my $B = $stuff->{a}{b}{c}{d}{f};
> my $C = $stuff->{a}{b}{c}{d}{g};
>
> # Version 2
>
> my $tmp = $stuff->{a}{b}{c}{d};
> my $A = $tmp->{e};
> my $B = $tmp->{f};
> my $C = $tmp->{g};
>
> What is the most efficient?
Who cares? (Seriously, unless you've determined that you have a
performance problem and that this bit of code is responsible, it's not
worth compromising readability.)
> What appears to be the most idiomatic?
The second. One of the more important rules of programming is DRY:
'Don't Repeat Yourself'. The first repeats a whole lot of stuff
unnecessarily.
Ben
------------------------------
Date: Thu, 13 Jun 2013 09:06:20 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Deep structure access and temp variable
Message-Id: <aqqjr8p91j0plvqiaabv2kieb37bv68cj1@4ax.com>
Adrien BARREAU <adrien.barreau@live.fr> wrote:
>A simple question, but I have no clue about it:
>
># Version 1
>my $A = $stuff->{a}{b}{c}{d}{e};
>my $B = $stuff->{a}{b}{c}{d}{f};
>my $C = $stuff->{a}{b}{c}{d}{g};
>
># Version 2
>
>my $tmp = $stuff->{a}{b}{c}{d};
>my $A = $tmp->{e};
>my $B = $tmp->{f};
>my $C = $tmp->{g};
>
>What is the most efficient?
Most efficient in regard to what? No, I'm not joking but I really mean
it. I'm guessing you are referring to runtime but that is by no means
the rule-it-all. Actually, if you program is so slow that you have to
optimize on this micro-level, then you should look for a better
algorithm or a different programming language.
Having said that I would guess the runtime depends upon how large $tmp
is. In version 2 you are creating a copy of the data. This can be 'slow'
for large data. If you want a trustworthy answer you will have to
benchmark both versions using your(!) live date.
But that really doesn't matter that much because ....
>What appears to be the most idiomatic?
... much more important than runtime micro-optimization is
maintainability of your code. And assuming that you can find a more
meaningful name than $tmp, then the second version wins hands-down in
that department.
And that kind of efficiency wins in the long run.
jue
------------------------------
Date: Thu, 13 Jun 2013 18:10:27 +0200
From: Adrien BARREAU <adrien.barreau@live.fr>
Subject: Re: Deep structure access and temp variable
Message-Id: <kpcqkg$m13$1@dont-email.me>
On 06/13/2013 05:55 PM, Ben Morrow wrote:
>
> Quoth Adrien BARREAU<adrien.barreau@live.fr>:
>>
>> A simple question, but I have no clue about it:
>>
[cut]
>>
>> What is the most efficient?
>
> Who cares? (Seriously, unless you've determined that you have a
> performance problem and that this bit of code is responsible, it's not
> worth compromising readability.)
>
Well, I do. I would not ask if I were not, would I?
I'm working on some piece of code which must run as fast as possible (in
Perl limits), hence the question.
And a bit of curiosity, too.
>> What appears to be the most idiomatic?
>
> The second. One of the more important rules of programming is DRY:
> 'Don't Repeat Yourself'. The first repeats a whole lot of stuff
> unnecessarily.
I agree.
That what I do for now. That was just in case.
Thanks :).
Adrien.
------------------------------
Date: Thu, 13 Jun 2013 18:13:46 +0200
From: Adrien BARREAU <adrien.barreau@live.fr>
Subject: Re: Deep structure access and temp variable
Message-Id: <kpcqqn$m13$2@dont-email.me>
On 06/13/2013 05:18 PM, Rainer Weikusat wrote:
>> What is the most efficient?
>
> This depends on the relative cost of the additional assignment versus
> that of the dereferencing chain. I usually follow the rule of thumb
> that using an intermediate variable only makes sense if it is going to
> be used for at least three times.
>
> But there's a more important concern: Readiblity of the code and the
> ease with which it can be modified: Both suffer in case of 'obnoxious
> repetition', as in your first example. Also, the intermediate variable
> could have a more sensible name than $tmp which could communicate its
> nature better the $stuff->{a}{b}{c}{d}.
>
>> What appears to be the most idiomatic?
>
> Is you're asking about "what everyone else does" you can rest assured
> that no problem which can be solved with copy'n'paste will be solved
> with anything but copy'n'paste because this minimizes that time of
> each individual 'trivial work unit' (also, people greatly prefer
> moving over thingking).
ACK.
Thanks :).
Adrien.
------------------------------
Date: Thu, 13 Jun 2013 18:14:07 +0200
From: Adrien BARREAU <adrien.barreau@live.fr>
Subject: Re: Deep structure access and temp variable
Message-Id: <kpcqrc$m13$3@dont-email.me>
[cut]
>> What is the most efficient?
>
> Most efficient in regard to what? No, I'm not joking but I really mean
> it. I'm guessing you are referring to runtime but that is by no means
> the rule-it-all. Actually, if you program is so slow that you have to
> optimize on this micro-level, then you should look for a better
> algorithm or a different programming language.
>
> Having said that I would guess the runtime depends upon how large $tmp
> is. In version 2 you are creating a copy of the data. This can be 'slow'
> for large data. If you want a trustworthy answer you will have to
> benchmark both versions using your(!) live date.
>
> But that really doesn't matter that much because ....
>
>> What appears to be the most idiomatic?
>
> ... much more important than runtime micro-optimization is
> maintainability of your code. And assuming that you can find a more
> meaningful name than $tmp, then the second version wins hands-down in
> that department.
> And that kind of efficiency wins in the long run.
>
ACK.
Thanks :).
Adrien.
------------------------------
Date: Thu, 13 Jun 2013 10:09:02 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: Deep structure access and temp variable
Message-Id: <130620131009024467%jimsgibson@gmail.com>
In article <kpcm7k$ra8$1@dont-email.me>, Adrien BARREAU
<adrien.barreau@live.fr> wrote:
> A simple question, but I have no clue about it:
>
> # Version 1
> my $A = $stuff->{a}{b}{c}{d}{e};
> my $B = $stuff->{a}{b}{c}{d}{f};
> my $C = $stuff->{a}{b}{c}{d}{g};
>
> # Version 2
>
> my $tmp = $stuff->{a}{b}{c}{d};
> my $A = $tmp->{e};
> my $B = $tmp->{f};
> my $C = $tmp->{g};
>
> What is the most efficient?
> What appears to be the most idiomatic?
>
> I don't have the knowledge about Perl guts to properly guess here.
> Of course, it does not have be only HASHes refs in the structure.
There is no need to guess. Perl has the Benchmark module that makes
doing these kind of comparisons relatively easy:
#!/usr/bin/perl
use warnings;
use strict;
use Benchmark qw(cmpthese);
my $stuff = { a => { b => { c => { d => { e => 1, f => 2, g => 3 }}}}};
cmpthese( 1_000_000, {
'Deep' => sub {
my $x = $stuff->{a}{b}{c}{d}{e};
my $y = $stuff->{a}{b}{c}{d}{f};
my $z = $stuff->{a}{b}{c}{d}{g};
},
'Temp' => sub {
my $tmp = $stuff->{a}{b}{c}{d};
my $x = $tmp->{e};
my $y = $tmp->{f};
my $z = $tmp->{g};
}});
__END__
Results from five runs:
41% perl barreau.pl
Rate Deep Temp
Deep 591716/s -- -63%
Temp 1612903/s 173% --
42% perl barreau.pl
Rate Deep Temp
Deep 621118/s -- -32%
Temp 917431/s 48% --
43% perl barreau.pl
Rate Deep Temp
Deep 854701/s -- -20%
Temp 1063830/s 24% --
44% perl barreau.pl
Rate Deep Temp
Deep 740741/s -- -24%
Temp 970874/s 31% --
45% perl barreau.pl
Rate Deep Temp
Deep 793651/s -- -17%
Temp 961538/s 21% --
That is a lot of variation from run to run, but the Temp approach is
clearly faster, which I would expect. It requires seven hash lookups
instead of fifteen.
As far as "idiomatic", I wouldn't worry about it. One person's
idiomatic is another person's idiotic.
--
Jim Gibson
------------------------------
Date: Thu, 13 Jun 2013 11:05:31 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Deep structure access and temp variable
Message-Id: <r42kr899p0nkp0e4r34jfr2dm2cvo0cu7e@4ax.com>
Jim Gibson <jimsgibson@gmail.com> wrote:
>In article <kpcm7k$ra8$1@dont-email.me>, Adrien BARREAU
><adrien.barreau@live.fr> wrote:
>
>> A simple question, but I have no clue about it:
>>
>> # Version 1
>> my $A = $stuff->{a}{b}{c}{d}{e};
>> my $B = $stuff->{a}{b}{c}{d}{f};
>> my $C = $stuff->{a}{b}{c}{d}{g};
>>
>> # Version 2
>>
>> my $tmp = $stuff->{a}{b}{c}{d};
>> my $A = $tmp->{e};
>> my $B = $tmp->{f};
>> my $C = $tmp->{g};
>>
>> What is the most efficient?
>> What appears to be the most idiomatic?
>>
>> I don't have the knowledge about Perl guts to properly guess here.
>> Of course, it does not have be only HASHes refs in the structure.
>
>There is no need to guess. Perl has the Benchmark module that makes
>doing these kind of comparisons relatively easy:
>
[...]
A very good example for "Wer mißt mißt Mist" (literal: "who measures,
measures manure").
>That is a lot of variation from run to run, but the Temp approach is
>clearly faster, which I would expect. It requires seven hash lookups
>instead of fifteen.
Completely irrelevant because your sample code is not using the OPs
actual live data or at the very least a representative sample of his
live data.
And depending on the size of $tmp this will make a big difference.
jue
------------------------------
Date: Thu, 13 Jun 2013 15:50:20 +0100
From: Justin C <justin.1303@purestblue.com>
Subject: How to minimize server load when program is run
Message-Id: <cq2p8a-i37.ln1@zem.masonsmusic.co.uk>
My web-hosts are running perl 5.8.8, other software there is of a
similar age, and some things are missing (I wanted to 'nice' my
program, but there is no 'nice').
I have written a backup program to tar and gzip my entire directory
tree on their site, and also to dump the db and add that to the tar.
The program I have written runs one of my cores at 100% for two
minutes, and uses almost 100MB RAM. If there is a way I'd like to
reduce this load (as I can't 'nice' it).
I haven't tried running the program yet, I don't want to get a
bad name for maxing out the hardware. I've used core modules only,
and I've used them as per documentation for the versions that were
part of 5.8.8. I've pasted the code below, I'd be grateful for
suggestions on how I could do the same while putting as little
load on the server as possible.
~ $ cat bin/wp-backup.pl
#!/usr/bin/perl
use warnings;
use strict;
use Archive::Tar;
use File::Find;
# global vars
chomp (my $now = `date +"%Y-%m-%d-%H%M"`);
my $tar;
my $file = "site.com.$now.tar.gz";
my $backup_dir = '/var/sites/s/site.com/backups';
create_archive();
my $db = extract_db_data();
$tar->add_files($db);
$tar->write($archive, 9);
sub archive_it {
my $new_name = 'public_html/' . $_;
(my $old_name = $File::Find::name) =~ s/^\///;
$tar->add_files($File::Find::name);
$tar->rename($old_name, $new_name);
}
sub create_archive {
my $www_dir = '/var/sites/s/site.com/public_html';
$tar = Archive::Tar->new; # declared in globals
find(\&archive_it, $www_dir); # &archive_it adds it to the tar
$tar->write($archive);
}
sub extract_db_data {
my $db = {
user => 'name',
pass => 'password',
name => 'db',
file => "site.com.$now.sql",
host => '1.0.0.0',
};
my @args = ('mysqldump', '--add-drop-table', '--complete-insert',
'--extended-insert', '--hex-blob', "--host $db->{host}", "--user=$db->{user}",
"--password=$db->{pass}", $db->{name}, '>', "$backup_dir/$db->{file}");
system @args == 0 or die "problem running mysqldump: $!";
return $db_file;
}
__END__
Thankyou for any help or suggestions.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Thu, 13 Jun 2013 17:17:42 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: How to minimize server load when program is run
Message-Id: <51b9e296$0$15954$e4fe514c@news2.news.xs4all.nl>
On 13/06/2013 16:50, Justin C wrote:
> The program I have written runs one of my cores at 100% for two
> minutes, and uses almost 100MB RAM. If there is a way I'd like to
> reduce this load (as I can't 'nice' it).
If you want to nice it, see POSIX::nice().
--
Ruud
------------------------------
Date: Thu, 13 Jun 2013 08:45:22 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: How to minimize server load when program is run
Message-Id: <130620130845223260%jimsgibson@gmail.com>
In article <cq2p8a-i37.ln1@zem.masonsmusic.co.uk>, Justin C
<justin.1303@purestblue.com> wrote:
> My web-hosts are running perl 5.8.8, other software there is of a
> similar age, and some things are missing (I wanted to 'nice' my
> program, but there is no 'nice').
>
> I have written a backup program to tar and gzip my entire directory
> tree on their site, and also to dump the db and add that to the tar.
> The program I have written runs one of my cores at 100% for two
> minutes, and uses almost 100MB RAM. If there is a way I'd like to
> reduce this load (as I can't 'nice' it).
>
> I haven't tried running the program yet, I don't want to get a
> bad name for maxing out the hardware. I've used core modules only,
> and I've used them as per documentation for the versions that were
> part of 5.8.8. I've pasted the code below, I'd be grateful for
> suggestions on how I could do the same while putting as little
> load on the server as possible.
What about doing a sleep(1) after every n files (or n bytes or n
seconds)? Your program will still max out a CPU while it is active, but
the average usage will be less. If you sleep(1) after each 1 second of
execution, then your program will take 4 minutes to run and use 50% of
a CPU.
--
Jim Gibson
------------------------------
Date: Thu, 13 Jun 2013 17:18:00 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How to minimize server load when program is run
Message-Id: <ou7p8a-mpb2.ln1@anubis.morrow.me.uk>
Quoth Justin C <justin.1303@purestblue.com>:
> My web-hosts are running perl 5.8.8, other software there is of a
> similar age, and some things are missing (I wanted to 'nice' my
> program, but there is no 'nice').
>
> I have written a backup program to tar and gzip my entire directory
> tree on their site, and also to dump the db and add that to the tar.
> The program I have written runs one of my cores at 100% for two
> minutes, and uses almost 100MB RAM. If there is a way I'd like to
> reduce this load (as I can't 'nice' it).
>
> I haven't tried running the program yet, I don't want to get a
> bad name for maxing out the hardware. I've used core modules only,
> and I've used them as per documentation for the versions that were
> part of 5.8.8. I've pasted the code below, I'd be grateful for
> suggestions on how I could do the same while putting as little
> load on the server as possible.
>
> ~ $ cat bin/wp-backup.pl
> #!/usr/bin/perl
> use warnings;
> use strict;
> use Archive::Tar;
If you're worried about memory use tar(1) is probably more parsimonious
than Archive::Tar, not least because it doesn't try to build the entire
tarball in memory before writing it out. Of course, you may not have
tar(1)...
You could also use something like Archive::Tar::Streamed, possibly
passing it a pipe to gzip(1) or an IO::Compress::Gzip filehandle. (If
you don't have IO::Compress::Gzip use IO::Zlib instead. You must have
that, Archive::Tar requires it.)
> use File::Find;
>
> # global vars
> chomp (my $now = `date +"%Y-%m-%d-%H%M"`);
Ouch! POSIX::strftime.
> my $tar;
> my $file = "site.com.$now.tar.gz";
> my $backup_dir = '/var/sites/s/site.com/backups';
>
> create_archive();
> my $db = extract_db_data();
>
> $tar->add_files($db);
> $tar->write($archive, 9);
>
> sub archive_it {
> my $new_name = 'public_html/' . $_;
> (my $old_name = $File::Find::name) =~ s/^\///;
> $tar->add_files($File::Find::name);
> $tar->rename($old_name, $new_name);
> }
> sub create_archive {
> my $www_dir = '/var/sites/s/site.com/public_html';
>
> $tar = Archive::Tar->new; # declared in globals
> find(\&archive_it, $www_dir); # &archive_it adds it to the tar
> $tar->write($archive);
> }
> sub extract_db_data {
> my $db = {
> user => 'name',
> pass => 'password',
> name => 'db',
> file => "site.com.$now.sql",
> host => '1.0.0.0',
> };
>
> my @args = ('mysqldump', '--add-drop-table', '--complete-insert',
> '--extended-insert', '--hex-blob', "--host $db->{host}", "--user=$db->{user}",
> "--password=$db->{pass}", $db->{name}, '>', "$backup_dir/$db->{file}");
^^^
Nope, that won't work. That will pass the '>' as a literal argument to
mysqldump, when you want it interpreted as a redirection. You need to
use 1-arg system (and be careful about your quoting) or do the whole
fork/dup/exec dance by hand.
> system @args == 0 or die "problem running mysqldump: $!";
Ben
------------------------------
Date: Thu, 13 Jun 2013 09:09:28 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Is there a better way than this?
Message-Id: <8q7o8a-l3t.ln1@news.rtij.nl>
On Tue, 11 Jun 2013 00:15:19 +0100, Ben Morrow wrote:
> Quoth tmcd@panix.com:
>> In article <qr5h8a-v4h.ln1@anubis.morrow.me.uk>,
>> Ben Morrow <ben@morrow.me.uk> wrote:
>>
>> >... builtins which take a LIST argument in perlfunc are list operators
>>
>> return EXPR
>>
>> return
>>
>> Returns from a subroutine, eval, or do FILE with the value given in
>> EXPR. Evaluation of EXPR may be in list, scalar, or void context,
>> depending on how the return value will be used, ...
>>
>> doesn't say LIST, but you say it's a list operator, and that makes ense
>> because it can return lists.
>
> That's interesting, actually. For starters, the perlfunc entry is
> definitely wrong: regardless of the eventual context return gives to its
> arguments, it always parses as a list operator.
Nope, it doesn't say anything about how it parses, but how it evaluates,
and that is correct (on my 5.14):
$ perl -e 'sub x { return localtime time; } print x, "\n";'
298913511341631
$ perl -e 'sub x { return localtime time; } print scalar(x), "\n";'
Thu Jun 13 09:08:49 2013
M4
------------------------------
Date: Wed, 12 Jun 2013 20:19:26 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perfect Insider's Guide To Selling Hot Properties
Message-Id: <65eir85u5hmnndh5nah4dgl95lboircba4@4ax.com>
na zi <zina2889@gmail.com> wrote:
[...]
Isn't selling stolen property illegal and will be punished as fencing?
In other words: you are promoting a guide for commiting a crime?
jue
------------------------------
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 3963
***************************************
