Loading ...
Sorry, an error occurred while loading the content.

Performance Exploration (C++ Library)

Expand Messages
  • Bryan Ewbank
    There was a discussion here a while back -- wrapped up on 2004.10.26 by Don Caton -- about where performance is being lost, and a general theory that replacing
    Message 1 of 3 , Dec 14, 2004
    • 0 Attachment
      There was a discussion here a while back -- wrapped up on 2004.10.26
      by Don Caton -- about where performance is being lost, and a general
      theory that replacing the scanner with lex would help quite a bit:

      http://article.gmane.org/gmane.comp.parsers.antlr-interest/1283

      Well, I was curious (and there's a very good C++ example - thanks
      Ric!), so I replaced my ANTLR scanner with lex. Using gprof, I
      learned that I saved around 10%. That's okay, I guess. Not what I'd
      hoped for, but good enough to switch.

      What surprised me is that the stuff associated with antlr::ASTRefCount
      accounted for nearly 40% of the time reported in gprof. On the one
      hand, this makes some sense (the "forwarding" methods account for
      around 15% of overall time) - but I was surprised to see assignment
      taking nearly 10% of the time.
    • Ric Klaren
      Hi, ... Only 10%? Hmm would have expected more going on some other figures I heart about. ... Ah looks like you use a lot of treewalker stuff. But... Ugh. I m
      Message 2 of 3 , Dec 14, 2004
      • 0 Attachment
        Hi,

        On Tue, 14 Dec 2004 10:01:42 -0500, Bryan Ewbank <ewbank@...> wrote:
        > There was a discussion here a while back -- wrapped up on 2004.10.26
        > by Don Caton -- about where performance is being lost, and a general
        > theory that replacing the scanner with lex would help quite a bit:
        >
        > http://article.gmane.org/gmane.comp.parsers.antlr-interest/1283
        >
        > Well, I was curious (and there's a very good C++ example - thanks
        > Ric!), so I replaced my ANTLR scanner with lex. Using gprof, I
        > learned that I saved around 10%. That's okay, I guess. Not what I'd
        > hoped for, but good enough to switch.

        Only 10%? Hmm would have expected more going on some other figures I
        heart about.

        > What surprised me is that the stuff associated with antlr::ASTRefCount
        > accounted for nearly 40% of the time reported in gprof. On the one
        > hand, this makes some sense (the "forwarding" methods account for
        > around 15% of overall time) - but I was surprised to see assignment
        > taking nearly 10% of the time.

        Ah looks like you use a lot of treewalker stuff. But... Ugh. I'm
        currently tinkering with the refcounters for 2.7.5 release (trying to
        make things play nice with the ones contributed by Mark Lentzcer (sp?)
        ) Anycase I'm more and more of the opinion that I *really* want to get
        rid of these damn things, and that was without looking at the
        performance picture which you now provide (thanks!)

        The one thing I'm currently worried about is backwards compatability
        for the 2.7.5 release I had planned to release with the new reference
        counter, but I'm at a point that I'm inclined to back out all those
        changes and release 2.7.5 with the old ones. (It just feels like
        shuffling the problem around to other parts of the code)

        Also if I include the new ones we'll be dropping MSVC6 support.

        Cheers,

        Ric
      • Don Macpherson
        ... Given that Microsoft have essentially dropped support for MSVC6, that wouldn t seem to be a serious impost. According to
        Message 3 of 3 , Dec 15, 2004
        • 0 Attachment
          >Also if I include the new ones we'll be dropping MSVC6 support.

          Given that Microsoft have essentially dropped support for MSVC6, that
          wouldn't seem to be a serious impost.

          According to http://support.microsoft.com/gp/lifedevtool:
          "Mainstream support for Visual C++ 6.0 will end in September 2004. Extended
          support will end in September 2005"

          Its time that we moved to ANSI standards-compliant compilers.


          Don
        Your message has been successfully submitted and would be delivered to recipients shortly.