in reply to Code Efficiency

1. Lose the parens () around a variable declaration (just my $PWD;). Edit on Abigail: this is just a style issue, unless you need the parens, i'd omit them.
2. Do not use @KeyWords, just put them in the hash as you find them:
foreach (split (/,/,$Line)) { $een{$_}++; }
3. Declare variables as late as possible (if you want the advantages of use strict;).
4. I assume you use @DirList and @SUBDirList because you can't 'flatten' the directory structure? There is not real speed problem here but my instinct tells me to lose the two arrays and open the subdirs in a while loop of the readdir(DIR).

These are all minor items, none of them speed up the most time-consuming part.

Replies are listed 'Best First'.
Re: Code Efficiency
by Abigail-II (Bishop) on Mar 25, 2004 at 13:11 UTC
    Lose the parens () around a variable declaration (just my $PWD;).
    Why? It's utterly useless to give "suggestions" without motivating them. It's even more useless to give suggestions that appear to be general, but which are sometimes plain wrong. There's a difference between my $var and my ($var), and while sometimes it doesn't matter whether you place the parens (like in the code being discussed), it sometimes changes the meaning of the expression. You seem to think it matters in this case. Could you explain why?

    Declare variables as late as possible (if you want the advantages of use strict;).
    Huh? While declaring variables in an as restrictive scope as necessary is usually a good thing, what does that have to do with any advantage of use strict?

    Abigail

      Declare variables as late as possible (if you want the advantages of use strict;). -- Huh? While declaring variables in an as restrictive scope as necessary is usually a good thing, what does that have to do with any advantage of use strict?

      The first use of a variable is usually important for consequent uses. If you declare the variable as late as possible, you make sure the program breaks when you remove the first use, but not all others.

      my $foo; # Predeclared: bad style # Usually done by C-coders, who predeclare a whole bunch of variables: # my ($foo, $bar, $baz, $quux, $whatever, $i, $think, $is, $needed, $a +nywhere); ... $foo = foo(); ... print $foo;
      Now, I remove the assignment:
      my $foo; ... print $foo; # No error, just a warning at run time.
      However, if you declare $foo as late as possible:
      my $foo = foo(); # Declared when needed ... print $foo;
      Removing the assignment again:
      ... print $foo; # Error at compile time!

      Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

        Yes, but what does that have to do with my question?

        Abigail

Re: Re: Code Efficiency
by fourmi (Scribe) on Mar 25, 2004 at 11:53 UTC
    cool, thanks a lot, useful stuff i wouldn't have thought about, i agree that the guts are going to take ages anyway though!
    cheers
Re: Re: Code Efficiency
by Juerd (Abbot) on Mar 25, 2004 at 13:15 UTC

    een

    What is een? Are you one of those people who have rrays and calars?

    Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      What is een? Are you one of those people who have rrays and calars?

      Actually, calar would be very nice looking name (when compared to other two) :D.

        Actually, calar would be very nice looking name (when compared to other two) :D.

        Except of course that $rray_reference and @calars suck.

        *lob? &ub? %ash? ILEHANDLE?

        Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      yup ;o)