Are there any significant disadvantages to doing this?

[MrCBofBCinTX]

I am trying to accomplish two things, speed and readability.

I have moved from an if elsif list of options to this:

# earlier:

my @available_commands # In modules
    = qw(ViewRecords
         InsertRecordGroupForm
         UpdateRecordForm
         InsertRecordGroup
         UpdateRecord
         DeleteDuplicates
         ShowColumns
         ShowTables
        );

# later:

if (! grep {$_ eq $command} @available_commands) {
    ErrorMessages($r, $lang, "un comando valido", "a valid command");
    goto ERROR_END;
}
else {
    $dbh->{AutoCommit} = 0;
    my $sub = \&{"$command"};
    &$sub( $r, $dbh, $q, $database, $program, $lang );
    $dbh->commit();
    $dbh->{AutoCommit} = 1;
}

This has excellent readability, but how does this effect speed and memory usage?
I am running mod_perl.

 

[feherke]

Hi

Just one thing to mention, as I am not versed in Perl optimizations :
[ul]
[li]the [tt]grep[/tt] function returns an array of all matches, so will always loop over the entire array[/li]
[li]the [tt]~~[/tt] ( smartmatch ) operator returns a boolean value, so will exit the loop only on the first match[/li]
[/ul]
So I would prefer the smartmatch operator, both for speed and readability considerations.


Feherke.
[link feherke.github.com/]

http://feherke.github.com/

[/url]

 

[MrCBofBCinTX]

I already have the available commands ordered in the most likely order they are to be called.
I will change to this:

if ($command~~@available_commands) {
    $dbh->{AutoCommit} = 0;
    my $sub = \&{"$command"};
    &$sub( $r, $dbh, $q, $database, $program, $lang );
    $dbh->commit();
    $dbh->{AutoCommit} = 1;
}
else {
    ErrorMessages($r, $lang, "un comando valido", "a valid command");
    goto ERROR_END;
}

 

[ChrisHunt]

This has excellent readability, but how does this effect speed and memory usage?

Before I answer that, can I ask you a couple of questions?
[ul]
[li]Is your code going to be used to, for example, control an aircraft - converting twitches of the joystick into dramatic movements at tremendous speed?[/li]
[li]Is it going to be used deep inside a loop, executed a gazillion times before the user sees the results of their actions?[/li]
[/ul]
If the answer to those questions is "no", then readability and maintainablity are way, way, WAY more important than (possibly) shaving a nanosecond off the execution time.

I know impatience is one of the three programming virtues that Perl is built upon, but if it runs fast enough, I wouldn't worry overmuch about it.

FWIW, I don't think this approach - even before feherke's enhancement - would consume a significant amount of time or memory.

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd

 

[MrCBofBCinTX]

OK.

Basically, this app runs on a remote server with web access.
It is mod_perl, perl dbi to PostgreSQL which also has stored procedures.
I am trying to improve readability and maintainability.
I have eliminated a lot of silly loops and tests, moving that stuff, after improvement, from the modules to very early spots in the program that feeds off to modules.

I'm no SQL superstar and have bit by bit improved the stored procedures, which can take a long time to run whenever certain items are updated since that items run upward into assemblies into bigger ones, etc. This process actually takes a noticeable amount of time.

But I do run it on my very old low memory laptop for development or when I cannot get to the internet. It runs very slow.
So for my circumstances, any loops or SQL that I can improve in the perl part seems worthwhile to me, but yes, that comes second or third on the list.
This one item is small, but it is the long set of bad code that I am trying to ditch.