RFC: config::simple vs config::ini

[thanos1983]

Dear all,

Recently I discovered, thanks to people of this forum the use of Benchmark. A great powerful tool comparing speeds, processes and times.

Well since I love playing around with details I could not resist to make this make not useful test and compare the Config::IniFiles Vs Config::Simple.I decided to run an experiment and observe the output.

Update:

Thanks to Anonymous Monk and davido for their contributions and suggestions, I have modified my experiment and came up with new data.

The experimental code:

#!/usr/bin/perl

use strict;
use warnings;
use List::Compare;
use Config::Simple;
use Config::IniFiles;
use Fcntl qw(:flock);
use Benchmark qw(:all) ;
use Data::Dumper qw(Dumper);

$|=1; #flush every time the program

=flock
    sub LOCK_SH { 1 } ## shared lock
    sub LOCK_EX { 2 } ## exclusive lock
    sub LOCK_NB { 4 } ## non-blocking
    sub LOCK_UN { 8 } ## unlock
=cut

my %information;
my $path = 'conf.ini';

my $count = -5 || die "Need a count!\n";

sub complex {
    
    open my $fh , '<' , "".$path."" 
    or die "Could not open file: ".$path." - $!\n";

    flock($fh, LOCK_SH)
    or die "Could not lock '".$fh."' - $!\n";

    tie my %ini, 'Config::IniFiles', ( -file => "".$path."" )
    or die "Error: IniFiles->new: @Config::IniFiles::errors";

    close ($fh)
    or die "Could not close '".$path."' - $!\n";

    print Dumper(\%ini);

    return %ini;

} # end sub complex

sub val {

    open my $fr , '<' , "".$path."" 
    or die "Could not open file: ".$path." - $!\n";

    flock($fr, LOCK_SH)
    or die "Could not lock '".$fr."' - $!\n";

    my $cfg = Config::IniFiles->new( -file => "".$path."" )
    or die "error: IniFiles->new: @Config::IniFiles::errors";

    close ($fr)
    or die "Could not close '".$path."' - $!\n";

    my $values = $cfg->val( 'Perl', 'test' );

    my @array = split(',', $values);
    
    print Dumper(\@array);

    return @array;

} # End of sub val

sub simple {

    open my $fr , '<' , "".$path."" 
    or die "Could not open file: ".$path." - $!\n";

    flock($fr, LOCK_SH)
    or die "Could not lock '".$fr."' - $!\n";

    Config::Simple->import_from( "".$path."", \%information)
    or die Config::Simple->error();

    close ($fr)
    or die "Could not close '".$path."' - $!\n";
    
    print Dumper(\%information);

    return %information;

} # End of sub simple

my $r = timethese ( $count , 
            { 'complex' => '&complex',
              'val'     => '&val',
              'simple'  => '&simple' } );
cmpthese $r;

I am using a common conf.ini folder that both scripts are reading from with flock process applied since I am planning to use in combination with other scripts.

Sample of the conf.ini folder:

[Perl]
test= bar,baz,foo,quux

The results after the test are the following:

val:  6 wallclock secs ( 5.69 usr +  0.30 sys =  5.99 CPU) @ 989.98/s 
+(n=5930)
          Rate complex     val  simple
complex  700/s      --    -29%    -46%
val      990/s     41%      --    -24%
simple  1297/s     85%     31%      --

Well to be honest I was expecting the complex version of Config::IniFiles to be faster in comparison to Config::Simple due to simplicity of the code. But the results have proved my assumption wrong. Thanks to Anonymous Monk that he elaborate regarding the tie and OOP process I decided to add also the val process to make it more fair. Also davido point out that the unlock process is a trap and possibly the data can still remain within the process, so it is better to close the file in order to flush the output.

Again thank you all for your contribution, to beginners like my self this is a big boost on the learning curve.

Well I do not know if this comparison makes any sense to anyone. But since I am beginner and all of this stuff make a huge impression, I felt it would be nice to mention this. Just in case that someone needs to use one of these two solutions to get also an idea about speed.

[davido]

Whenever I see LOCK_UN, I think of File Locking Tricks and Traps, Trap #1: LOCK_UN. You usually are better served by letting files unlock as their handles fall out of scope or are explicitly closed. You're not writing to the files, so it's unlikely to matter, but LOCK_UN is not a useful part of most solutions. Its uses are complex and not common.

[thanos1983]

To: Davido,

Nice!!!, I had no clue for that trap. Well I found that by closing the file the unlock happens automatically File Locking.

So regarding the reason that I am using flock on reading. I was planning to possible extend my conf.ini file by writing into it while some processes might reading. I just wanted to compare the process with all having this extra feature (flock), before I conclude which one to use.

Thank you for pointing out all this information, beginners like me learn so much.

[Jenda]

Erm ... why???

I mean, configs are in general small and loaded just once so the time spent loading and parsing the data is 1. negligible and 2. mainly the time it takes to read the data from the hard drive/network if it's not already in cache. It might make some tiny sense to measure the access to the already read data, but the loading itself is best left outside the benchmark.

I do believe the choice of the config reader should depend only on the format of the config file and the API it provides. Anything else is a premature microoptimization which is as we all know the root of all evil.

[thanos1983]

To: Jenda,

You are right most of the time the *.ini files are loaded just once. The reason that I implement this experiment is that I wanted to become familiar with all possibilities of parsing data through *.ini and secondary some times I am creating while(sleep 1) loops with scripts that include MySQL syntax. In such cases again it does not make a big difference, but I thought it would be fun to apply and find the most suitable solution to my needs.

In conclusion, I did not find any documentation that could include all of them together. So I thought why not write something by my self experiment and contribute to least possible degree.

[Anonymous Monk]

tie is slower than OOP

[thanos1983]

To: Anonymous Monk,

Thank you for the explanation, now makes more sense. Why the "simple" is faster than "complex".