in reply to Re^2: snmpget is missing some values
in thread snmpget is missing some values

Re: "echo" vs. local print: "echo" is invoking an external command (New process), opening a file, and appending to it.
Doing that in perl would avoid the "process creation", and command parsing overhead (Probably nanoseconds, so no big deal). But, being a perl bigot, I'd prefer seeing it in perl. 
open my $log, ">>", "$path/register_list.txt" or die "Cannot append:$!
+";
print $log join( ",",$date,$client_ip,$client_imsi,$bsid),"\n";
close $log;

[download]
Re: Using a Database:
You could, potentially , have a BSID table, annd a CLIENT table, in addition to the log line,to track items. Dates would be better organized, and searching and filtering is easy to do.

I have a simple cgi application that presents the contents of a Sqlite DB, to a web page, enabling queries. This is why I would prefer a database.

        This is not an optical illusion, it just looks like one.

Replies are listed 'Best First'.
Re^4: snmpget is missing some values
by hippo (Archbishop) on Apr 13, 2016 at 22:43 UTC
    Probably nanoseconds, so no big deal

    I thought that sounded optimistically fast, so here's the benchmark:

    $ cat pore.pl 
#!/usr/bin/env perl 
use strict;
use warnings;
use Benchmark 'cmpthese';

open my $fh, '>', '/tmp/wp.txt' or die $!;
cmpthese (10000,
    {
        'print' => sub { print $fh "x\n"; },
        'echo'  => sub { system "echo x >> /tmp/we.txt"; }
    }
);
close $fh;
exit;
$ perl pore.pl 
            (warning: too few iterations for a reliable count)
                        Rate                 echo                print
echo                   317/s                   --                -100%
print 10000000000000000000/s 3153000000000000000%                   --

    [download]

    Yes, print is so much faster than shelling out each time it is practially immeasurable. They'll get closer if you do the open and close inside the sub of course and that would mean losing the buffering too but it's still going to beat the pants off a fork and a shell invocation each time just to do a one-line write.

    Upshot: on my machine here it isn't nanoseconds - it's more like 3 milliseconds.

[reply]
[d/l]
      Thanks for putting in the effort to test my wild guess (++).

      On my machine, Your test gets me 2174 echo per second, which is around 460 MICRO seconds each - yes , still not in NANO seconds.
      (It helps that I am writing to an SSD disk)

      I updated the code slightly to get closer to the "echo" open/close of the file, and append to it, and 10x the iterations: 

      use strict;
use warnings;
use Benchmark 'cmpthese';


cmpthese (100000,
    {
        'print' => sub { 
            open my $fh, '>>', '/tmp/wp.txt' or die $!;
            print $fh "x\n";
            close $fh;
             },
        'echo'  => sub { system "echo x >> /tmp/we.txt"; }
    }
);
exit;

      [download]
      This gives me: 
                Rate  echo print
echo    2168/s    --  -98%
print 140845/s 6397%    --

      [download]
      Where the perl performance is pushing the limits of nanoseconds, at 7100 nanoseconds per write.

      In any case, the lesson learned is that perl is about 70 times faster than "echo".

              This is not an optical illusion, it just looks like one.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom