Bug #59207 for Devel-Tokenizer-C: Long spans of == tests could be replaced by strcmp

Thu Jul 08 13:59:49 2010 khw [...] cpan.org - Ticket created

Subject:

Long spans of == tests could be replaced by strcmp

The perl core uses this module to generate keyword parsing. There are cases where there are long strings of, for example, if (name[0] == 'g' && name[1] == 'e' && name[2] == 't' && name[3] == 'p' && name[4] == 'r' && name[5] == 'o' && name[6] == 't' && name[7] == 'o' && name[8] == 'b' && name[9] == 'y' && name[10] == 'n' && name[11] == 'a' && name[12] == 'm' && name[13] == 'e') These could be replaced by a strcmp(name, "getprotobyname"). (Actually in perl, it would be a call to the macro memEQ instead, which resolves to an appropriate function on the target hardware. I propose that this module be enhanced to generate those things, with the constructor taking arguments as to the function to call, and the number of consecutive tests needed to change to use the function. I don't know what the default should be. It would depend on the particular platform, and its caching characteristics

Thu Jul 08 14:17:20 2010 mhx-perl [...] gmx.net - Correspondence added

CC:	karl williamson <public [...] khwilliamson.com>
Subject:	Re: [rt.cpan.org #59207] Long spans of == tests could be replaced by strcmp
Date:	Thu, 8 Jul 2010 20:17:03 +0200
To:	bug-Devel-Tokenizer-C [...] rt.cpan.org
From:	Marcus Holland-Moritz <mhx-perl [...] gmx.net>

Hi Karl, sorry for not replying to your first mail. I'm already working on implementing custom multi-char compare support for D::T::C. However, attempting to do it "right" as usual takes more time than initially predicted... ;) I'll also try to run some benchmarks when I'm done to see how this affects performance. Will keep you updated. Cheers, Marcus On 2010-07-08, at 13:59:50 -0400, Karl Williamson via RT wrote: Show quoted text

> Thu Jul 08 13:59:49 2010: Request 59207 was acted upon. > Transaction: Ticket created by khw > Queue: Devel-Tokenizer-C > Subject: Long spans of == tests could be replaced by strcmp > Broken in: (no value) > Severity: Wishlist > Owner: Nobody > Requestors: corporate@khwilliamson.com > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=59207 > > > > The perl core uses this module to generate keyword parsing. There are > cases where there are long strings of, for example, > if (name[0] == 'g' && > name[1] == 'e' && > name[2] == 't' && > name[3] == 'p' && > name[4] == 'r' && > name[5] == 'o' && > name[6] == 't' && > name[7] == 'o' && > name[8] == 'b' && > name[9] == 'y' && > name[10] == 'n' && > name[11] == 'a' && > name[12] == 'm' && > name[13] == 'e') > > These could be replaced by a strcmp(name, "getprotobyname"). (Actually > in perl, it would be a call to the macro memEQ instead, which resolves > to an appropriate function on the target hardware. > > I propose that this module be enhanced to generate those things, with > the constructor taking arguments as to the function to call, and the > number of consecutive tests needed to change to use the function. I > don't know what the default should be. It would depend on the > particular platform, and its caching characteristics

Download signature.asc
application/pgp-signature 198b

Message body not shown because it is not plain text.

Thu Jul 08 14:17:21 2010 The RT System itself - Status changed from 'new' to 'open'

Thu Jul 08 15:05:23 2010 khw [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #59207] Long spans of == tests could be replaced by strcmp
Date:	Thu, 08 Jul 2010 13:05:08 -0600
To:	bug-Devel-Tokenizer-C [...] rt.cpan.org
From:	Karl WIlliamson <corporate [...] khwilliamson.com>

mhx-perl@gmx.net via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=59207 > > > Hi Karl, > > sorry for not replying to your first mail. I'm already working on > implementing custom multi-char compare support for D::T::C. However, > attempting to do it "right" as usual takes more time than initially > predicted... ;)

I just wanted to make sure it didn't get spam-filtered out. I looked at the code myself, and saw that this was not a trivial change. Thanks for looking at it.