Gurus,
This may be merely a philosophical debate, but I have a
performance-related question regarding pre-allocation to hashes. Consider:
##################### Sample code #####################
use strict;
use warnings;
use Devel::Peek;
use constant HKEYS => 128; # Experimentally optimized, quality percentage
= 89.4 for 92 elements
my %hash; keys(%hash) = HKEYS;
# code to load %hash with values...
Dump( \%hash, 1); # To get performance data
##################### Sample code #####################
Now, I know %hash will have 92 elements, and that the hash quality
percentage (HQP) will be 89.4 (these are actual numbers, derived using a
real data set). The question is, can I achieve an increase in actual
performance (reduced runtime) by reducing the value of HKEYS to 64? I've
done some experimenting, and found that the HQP will be the same, and that
increasing HKEYS will actually decrease the quality (increases the HQP).
I'm aware of the way keys(%hash) operates--allocating the next higher
power of two elements (e.g.: for n = 1-16, keys(%hash) = n will allocate
16, n = 17 will get 32).
My established practice has been to keep the value(s) of HKEYS equal to or
greater than the known number of elements for each hash--it's this
practice that I've begun to question. So the question is this: Once I've
determined optimal values (minimum HQP) for HKEYS for my hashes, do I gain
anything in runtime performance if I decrease the pre-allocation below
those values (assuming that I don't get a percentage increase as a
result)?
I'm working with seven small hash data sets, ranging from 14 through 139
elements. I know, it's a small group of small data sets, I'm asking this
mainly for future reference, if/when larger sets come down the line.
Thanks!
Deane Rothenmaier
Programmer/Analyst -- IT-StdCfg
Walgreens Corp.
2 Overlook Point #N5102D
MS 6515
Lincolnshire, IL 60069
224-542-5150
People using flintlock pistols shouldn't fire warning shots. -- Andrew
Borntreger
_______________________________________________
ActivePerl mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
