Front page | perl.perl5.porters |
Postings from November 2012
Karl Williamson wrote: > On 11/25/2012 07:30 AM, bulk88 wrote: >> http://perl5.git.perl.org/perl.git/commitdiff/7af276bcacd71d557a403b1d416e975ea139994c >> >> why? There is no commit message. How did you come to that decision? >> > > I did not expand on the commit's subject line, because when it came to > write it, I couldn't think of anything that wasn't effectively just a > repeat of the subject line. > > Perhaps I made the wrong decision. In looking at it today, I think I > could have added the adjective "wrapper function" to it to make it clear > that there is no real meat in the to-be-inlined function. > > I presumed that the audience would know that inlining speeds things up > by avoiding function call overhead, and hence in general is a "good" > thing. And I presumed that they knew that the downside of inlining is > expansion of the memory occupied by the program. And so, it would have > been better to alleviate that concern by mentioning that the affected > function is just a wrapper, and hence its inlining doesn't appreciably > change the size of the code. What is your cost benefit cutoff for inlining? Is S_is_utf8_char_slow unconditionally called? Is S_is_utf8_char_slow hot (profiler or benchmark or educated guess or experience)? Was it used in so few places (I counted 3) the overhead of the call would exceed inlining it?Thread Previous | Thread Next