oldgeezer wrote:
>
> Hi all,
>
> Sorry for the late response, I've been busy doing something else.
That's cool.
> As a newbie in this perl.beginners, I did not know that it is a good thing to
> tell what purpose the script has. My script is purely hobby. All my scripts
> are.
As a general principle, a proper description of the problem will be very close
to a program that solves it. Try it and see.
> I understand it now, I simply overlooked:
>
>>> How many times do you create a new iteration
>>> variable <snip>
>
> And then someone replied:
>>> In either case ... do not worry.
>
> I did not worry. My script works okay, I only wondered why reshuffling a loop
> made a big difference in time.
It's a fair question. Remember that most people who post to this group don't
have English as their first language. It's unlikely that anyone meant to
chastise, and hobbyists are perhaps even more welcome than professionals who
have deadlines and targets and want a fast solution. The only proviso is that if
you are on a course and have been given homework to do then it is best if we
encourage thought and memory rather than simply providing an answer.
> I wasn't aware that a Benchmark module exists. Seems worth playing with it.
> Which I will do.
Sure. That's why I mentioned it :)
> The code I wrote in my question was only to give you an idea what I was
> talking about, not the real code because then I would have given the data
> that I work on as well. It is not secret data, but they are long lines and I
> was afraid they would wrap.
Beware of simplifying. If you are unable to find the source of a problem then
you are also unlikely to be able to reduce it while reliably maintaining the
environment.
The best advice, if you have a problem that you cannot resolve, is to minimize
both the program and the data as far as possible while keeping the misbehaviour.
In doing so you will likely find the solution yourself, but if not it leaves
fewer irrelevancies for other people to wade through.
> But you also made me aware of a mistake I always made until now. The three
> periods in
>
> for (x...y)
>
> I must have inherited that error from another language. Probably from an
> interpreter I wrote myself some 30 years ago.
You didn't make a mistake. There is very little difference between $x..$y and
$x...$y, and if the second operand is a constant then they are identical.
> Thanks for all the help.
You are welcome.
> Below I give you the original lines in my script. I usually write a lot of
> comment lines, because I know myself. After some time I forget why I did
> something, and then reinvent the wheel. The script is a CGI. Data in the data
> base is separated with a ';' (is that called a semi-colon? I am not native
> english).
It's called a semicolon - no hyphen :)
> foreach my $entry (uniq @IK){
> foreach my $line(@DATA) {
> # Note /;$entry;/ takes longer than
> # /$entry;/ and that takes longer than /$entry/
> # But /$entry/ also splits remarks_entries.
> # So I need the trailing ';' because they
> # are not in the remarks_entries
> # Appending the i, like: /$entry/i slows
> # down too. I don't need it.
> # Prepending m, like m/$entry/
> # does not change anything (timewise).
> # For the average person /$entry;/ is fastest
> if($line=~ /$entry;/) {
> splitline($line); [EMAIL PROTECTED] changes when I splitline
> #next; don't do this. It makes it slower
> };
> };
> };
Your comments are fine, but they have obscured your code structure. How about
# Note /;$entry;/ takes longer than /$entry;/ and that takes
# longer than /$entry/ But /$entry/ also splits
# remarks_entries. So I need the trailing ';' because they
# are not in the remarks_entries.
#
# Appending the i, like: /$entry/i slows down too. I don't
# need it. Prepending m, like m/$entry/ does not change
# anything (timewise). For the average person /$entry;/ is
# fastest
#
foreach my $entry (uniq @IK) {
foreach my $line (@DATA) {
if ($line=~ /$entry;/) {
splitline($line); # @IK changes when I splitline
#next; don't do this. It makes it slower
}
}
}
But even then I have issues with what your comments say. First of all you are
obsessed with speed over function. A programmer's primary duty is to make things
that work, and look like they work; it is only a secondary consideration to make
things faster if they turn out to be too slow.
> Appending the i, like: /$entry/i slows down too
I doubt it. Did you benchmark it? If it explains the purpose of your regex
better then you should use it regardless of the speed.
> Swapping the first two foreach-lines make a big time difference, @DATA is the
> data base and is about 5000 lines, @IK varies from 1 to around 20 strings,
> dependent on the request POSTed to the CGI-script.
No. Stop it! If your program takes a significant amount of time to run then it's
probably best to look at how your data is stored. You are writing an algorithm
that solves a problem. Forget speed altogether. Please.
> 'uniq' and 'splitline' are subs. There is a trick. @IK changes in the loop,
> but the 'uniq @IK' is only defined once and is not changed by the loop. The
> changed @IK is used later again for some other reason.
Then you are working with poorly-written subroutines. If this is indeed a hobby
then throw them away and rewrite.
> Oh, and those trailing ';' after all the '}' may well be superfluous. But I
> like to see when a } is really the end of a block and will not be followed by
> an else or something like that. I know: emacs does a nice indentation, but
> still I (personally) like to see that ';'
Get over it. You can add half a dozen semicolons after each line and they are
all superfluous. At the same time you have very little whitespace in your code,
and that is what helps to show structure. Add lots of whitespace and remove all
unnecessary punctuation and you will have a program that can be understood at a
glance. Even parentheses around subroutine parameters should be removed if
possible.
No spare semicolons please.
HTH,
Rob
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
