Don't do that. Well, not substitute a hash for bunch of global variables anyway. Instead use a light weight object:

use strict;
use warnings;

my $obj = bless {};

$obj->initMembers ();
$obj->print ();


sub initMembers {
    my ($self) = @_;

    $self->{hello} = "Hello World.\n";
}


sub print {
    my ($self) = @_;

    print $self->{hello};
}
[download]

The idea is to make the 'globals' into 'data members' so that their provenance is clear and avoid passing around a hash as a parameter everywhere (the member calling mechanism is doing that implicitly).

Don't get caught by the run time 'efficiency' snare. Any timing difference at the level you are asking about is so small that you can ignore it. Programmer efficiency gains are where you should be looking and that boils down to code that is easy to test and maintain. Writing tests for your code as you write the code is a strongly recommended practice.

Generally, keeping state in global data is a design mistake. And simply changing the global state from global variables to a global hash doesn't fix it.

Instead you should re-think the design of your program. Some relevant general software design tips taken from On Coding Standards and Code Reviews that might help are:

• Coupling and Cohesion. Systems should be designed as a set of cohesive modules as loosely coupled as is reasonably feasible.
• Testability. Systems should be designed so that components can be easily tested in isolation.
• Design the module's interface first.
• Data hiding. Minimize the exposure of implementation details.
• Minimize the use of global data.
• Minimize the scope of variables, pragmas, etc..

It'd add an extra level of dereferencing, and defeats strict speel chickin'.

Good software craftsmanship also almost never requires global variables.

Instead, you should be thinking about limiting a variable's scope to just the part of the program where it's needed. Look at each of your global variables, and see how much of your program they span. If they're actually only used in a dozen lines, then just have them exist for that scope.

About the only thing that might need to be global is some sort of configuration hash, but even then it's better to pass each routine the information they need, rather than have the routine grab the information from a magical, invisible global variable.

And that's the problem with global variables -- stuff gets magically added and changed, and it's tough to track down where that actually happened when 'something weird' starts to happen. Global variables are probably a rabbit hole you don't want to go down.

Update: Change 'also' to 'almost'. Language brain fart.

I'm working on a script and currently have a lot of global variables. Is it better to create a couple global hash key/values and incorporate the global vars into the hash?

Note it doesn't mean every global variable is "bad" - there are many cases where a global variable makes sense. And note there are many "hidden" global variables; in a naive, hashref based objects, its attributes are "global" as well - much more code can (unintended) touch them.

In doing so would this also speed up the script or slow it down?

1	It's actually a misnomer. The potential problems have to do with variables having a too broad scope. Even if a variable isn't truely global, it can still have a scope that's too broad.
2	Some people think "global variable" means "package variable". It doesn't. A lexical variable can be a global variable as well. You don't solve the "don't have global variables" issue by just sticking a my in front of them!