From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14204 invoked by alias); 20 Dec 2008 17:45:51 -0000 Received: (qmail 14193 invoked by uid 22791); 20 Dec 2008 17:45:50 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_MX,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 20 Dec 2008 17:45:15 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mBKHjEAC018264 for ; Sat, 20 Dec 2008 12:45:14 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mBKHjD92006450; Sat, 20 Dec 2008 12:45:13 -0500 Received: from opsy.redhat.com (vpn-12-180.rdu.redhat.com [10.11.12.180]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mBKHjCfD010540; Sat, 20 Dec 2008 12:45:12 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id EF03C888169; Sat, 20 Dec 2008 10:45:11 -0700 (MST) To: gdb-patches@sourceware.org Subject: Re: RFA: add C++ alternate punctuators References: <20081220171526.GA30284@caradoc.them.org> From: Tom Tromey Reply-To: Tom Tromey Date: Sat, 20 Dec 2008 17:45:00 -0000 In-Reply-To: <20081220171526.GA30284@caradoc.them.org> (Daniel Jacobowitz's message of "Sat\, 20 Dec 2008 12\:15\:26 -0500") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00360.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Daniel> Does anything performance sensitive use this lexer, or is that likely Daniel> in the future? I suspect this version will be quite a lot slower; Daniel> it has a string copy and a linear search. I don't know whether it is performance sensitive in general. I haven't tried profiling in this area. The string copy is already done in the not-a-keyword case. So, if this part of the patch negatively affects performance, then it would only do so for the case of expressions weighted toward use of keywords. That doesn't seem like a scenario worth worrying about. We already linearly search two other tables for every token, not just keywords. This doesn't justify adding another one, but it does suggest that it hasn't hurt so far. Anyway, the above was my reasoning when I wrote the patch. Also, I thought using a table would make it a little less error-prone to add new keywords in the future. (I think we are missing 7 relevant ones.) I can rewrite it to use a hash table if you'd prefer. Or just inline the new keywords into the switch and delete the comment. Let me know. Tom