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