develooper Front page | perl.perl5.porters | Postings from January 2018

Re: Porting/bench -- utf8 to code point speed up

Thread Previous | Thread Next
From:
Karl Williamson
Date:
January 30, 2018 22:45
Subject:
Re: Porting/bench -- utf8 to code point speed up
Message ID:
332e1dd4-f312-1f74-399e-67d2fa053f9b@khwilliamson.com
On 01/22/2018 12:25 PM, Karl Williamson wrote:
> On 10/31/2017 05:47 AM, Dave Mitchell wrote:
>>> The total size of ./perl increased 100K bytes.  There were 98 calls 
>>> in it
>>> that got inlined; only 6 needed the full generality.
>> Hmmm, that seems a bit excessive. I would be tempted to see what
>> performance drop you get by not inlining the function, or only inlining
>> it in a few critical places, or (if technically feasible) only inlining
>> a smaller subset of the function.
>>
> 
> I tried a non-inlined version, and get the attached results.  Again they 
> show a win in every case we care about,and the table could be modified 
> to give better results for larger code points.
> 
> The win isn't nearly as large as inlining.  The second attachment shows 
> the gain of inlining above and beyond the gain shown in the first 
> attachment.  We could decide to create an inlined version that the hot 
> code could call directly

After having worked with this some more, I think the solution should be 
to change the dfa to not accept non-character code points.  Then, if the 
dfa succeeds, the code point is never problematical, and we can just 
return it without testing.  This would make the inlined code smaller.

So for now, I just changed the regular translator to first use the dfa. 
This yields modest improvements.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About