how can c++ be slower than Perl?

Discussion in 'C++' started by jeffrey.bigham@gmail.com, Feb 1, 2006.

  1. Guest

    Hello,

    I'm writing a program that needs to read input line by line and analyze
    each, and it needs to be as efficient as possible. I wrote the
    following sample program that works, but is 10 times slower than a Perl
    equivalent on a large input (~212 Mb). There has to be something wrong
    - can anyone help me fix it? I've included both at the bottom of my
    post and I compile with g++ -03 cin_test.C

    Thanks!
    Jeff

    #include <string>
    #include <iostream>

    using namespace std;

    int main() {
    string my_string;
    while(cin) {
    getline(cin, my_string);
    }
    }

    The Perl "equivalent" that I used (verbatim) is:

    while (<>) { print if /someregex/; }
    , Feb 1, 2006
    #1
    1. Advertising

  2. * :
    >
    > I'm writing a program that needs to read input line by line and analyze
    > each, and it needs to be as efficient as possible. I wrote the
    > following sample program that works, but is 10 times slower than a Perl
    > equivalent on a large input (~212 Mb). There has to be something wrong
    > - can anyone help me fix it? I've included both at the bottom of my
    > post and I compile with g++ -03 cin_test.C
    >
    > Thanks!
    > Jeff
    >
    > #include <string>
    > #include <iostream>
    >
    > using namespace std;
    >
    > int main() {
    > string my_string;
    > while(cin) {
    > getline(cin, my_string);
    > }
    > }
    >
    > The Perl "equivalent" that I used (verbatim) is:
    >
    > while (<>) { print if /someregex/; }


    Your result is not surprising. C++ iostreams are notoriously
    inefficient, in most (all?) implementations. But the Perl bytecode
    interpreter is probably written in C, which is a mostly a subset of C++:
    that means you can do at least as well as the Perl interpreter.

    Things to improve performance even with C++ iostreams:

    * Use binary i/o (turn off that darned newline conversion).

    * Read a larger chunk of the file at a time (larger buffer).

    * Read into a statically allocated buffer (like Perl probably does)
    with a limit on line length, instead of std::string -- this
    trades some safety and functionality for efficiency.

    However, you can't force std::cin and std::cout to binary mode in a
    portable way (that's a design error with iostreams); with C++ iostreams
    you'll have to require a name file as input, or use some non-portable
    mechanism.

    So the upshot is that if you want to stay within the standard library,
    and have performance and guaranteed results, and have portable code, use
    low-level C FILE* (I'm not sure if the Boost library offers something).

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Feb 1, 2006
    #2
    1. Advertising

  3. wrote:
    > Hello,
    >
    > I'm writing a program that needs to read input line by line and analyze
    > each, and it needs to be as efficient as possible. I wrote the
    > following sample program that works, but is 10 times slower than a Perl
    > equivalent on a large input (~212 Mb). There has to be something wrong
    > - can anyone help me fix it? I've included both at the bottom of my
    > post and I compile with g++ -03 cin_test.C


    // Try this program instead...
    #include <string>
    #include <iostream>

    using namespace std;

    int main()
    {
    // Don't sync C++ and C I/O...
    ios_base::sync_with_stdio(false);
    string my_string;
    while(cin) {
    getline(cin, my_string);
    }
    return 0;
    }
    Greg Buchholz, Feb 1, 2006
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. abilash
    Replies:
    1
    Views:
    573
    Jim Lewis
    May 17, 2005
  2. Andre Charbonneau

    XPath queries getting slower and slower...

    Andre Charbonneau, Feb 15, 2005, in forum: Java
    Replies:
    0
    Views:
    541
    Andre Charbonneau
    Feb 15, 2005
  3. Jon Reed

    Is perl 5.8 slower than 5.005_03?

    Jon Reed, Dec 4, 2003, in forum: Perl Misc
    Replies:
    2
    Views:
    203
    Ilya Zakharevich
    Dec 4, 2003
  4. @
    Replies:
    53
    Views:
    623
    John Postlethwait
    Oct 21, 2004
  5. Yesterday Paid
    Replies:
    1
    Views:
    262
    Dave Angel
    Jun 21, 2012
Loading...

Share This Page