view release on metacpan or  search on metacpan

examples/benchmark.pl  view on Meta::CPAN

	my $count = 0;
	my $t0 = Time::HiRes::time();
	my $t_end = $t0 + $MIN_TEST_SECONDS;
	my $t1;
	do {
		&$_code();
		$t1 = Time::HiRes::time();
		$count++;
	} until ($t1 >= $t_end );
	my $duration = $t1 - $t0;
	print "$count iterations over $duration seconds, ".($count/$duration)." iterations per second\n";
	return [ $count, $duration ];
}

lib/Geo/Index.pm  view on Meta::CPAN

#. points and each search type was performed once for each point in random order.
#. The same points were used for each test and they were in the same order.  All
#. searches returned results as lists except for the 'all points' search which 
#. returned a list reference.  The default options (Earth, 20-level index) were 
#. used for each test.  Each version's benchmark was run 32 times; some jitter 
#. was observed.
#. 
#. Average number of operations per second using each version (rounded):
#. Percentages (in parentheses) are relative to the pure-Perl version.
#. 
#. Results for 32 iterations of each test:
#. 
#. Operation                            Perl     C double (%)    C float (%) 
#. --------------------------------    ------    ------------    ------------
#. Add point to index                   35861     36067 (101)     36060 (101)
#. Search: return all points           256127    256877 (101)    252116  (98)
#. Search: sort, max 5                   6733      8718 (129)      8860 (132)
#. Search: sort, radius 1000, max 5     45364     49063 (108)     49831 (110)
#. Search: sort, radius 1000            45902     49418 (108)     51673 (113)
#. Search: max 5                       198499    190404  (96)    204905 (103)
#. Search: radius 1000, max 5           46942     51295 (109)     54554 (116)

lib/Geo/Index.pm  view on Meta::CPAN

=head2 Technical discussion

Both C<L<Search(...)|/Search( ... )>> and C<L<SearchByBounds(...)|/SearchByBounds( ... )>> are very fast since 
they can find the relevant index tiles in linear time.  Since the time needed to 
filter the results is directly proportional to the number of points retrieved 
from the index, best performance occurs when the size of the most detailed tiles 
is smaller than that of the typical search radius or search bounds.

Searches run using C<L<Closest(...)|/Closest( ... )>> are done starting from the most 
detailed level and work upwards.  Best performance occurs when a result is found 
in the first few iterations.  If the first iteration that finds points yields a 
large number of points then performance will suffer since the distance to each 
of these points will need to be measured to find the closest.  For similar 
reasons, requesting a large number of closest points in a single call will also 
impact performance.  The C<L<Farthest(...)|/Farthest( ... )>> method is largely a wrapper for 
C<L<Closest(...)|/Closest( ... )>> and thus exhibits similar behavior.

Some functions within Geo::Index have optional implementations written in C.  If 
these are active (by default they are whenever possible) searches typically run 
25% to 50% faster.