On Wed, Jul 13, 2005 at 03:50:47PM +0100, [EMAIL PROTECTED] wrote: > Dave Mitchell <[EMAIL PROTECTED]> wrote: > :On Sat, Jul 02, 2005 at 04:53:35PM +0100, Dave Mitchell wrote: > :> On Sat, Jul 02, 2005 at 04:52:43PM +0100, [EMAIL PROTECTED] wrote: > :> > If I remember right, a lot of code tests whether the warning is enabled > :> > before testing whether the warning case applies, on the assumption that > :> > the first check is quick. Many of those cases may want to be re-evaluated > :> > in the light of this patch. > :> > :> I was going to save that for another day :-) > : > :That day has now arrived: > > The tipping point has moved less far than this patch implies: the new > ckWARN() function still takes pretty tightly bounded time, and should > be preferred over some of the less tightly bounded calls such as strchr(). > > Guessing (mostly), I think it should come before the function call in: > doio.c chunks #1, #3 > pp_hot.c chunk #2 > toke.c chunks #3, #4
I don't think it really makes that much difference, since the ckWARN is usually true and the strchr usually fails, but I've fixed up the chunks you suggested anyway. > Looking through the patch also suggests that the handling of Unicode > strings in general may be getting slowed down a lot by all the warnings > checks: as written, they're required to pass the right flags to the > low-level functions, but it might be possible to refactor the later > towards some new functions that would be able to defer the check until > a warnable condition were encountered. I tried to do some basic factoring out as I went along, but something more heavyweight probably needs doing too. Ironically, the low-level functions themsleves also do a ckWARN, so some refactoring is definitely in order. I'll probably have a look at this at the same time as I get round to fixing the $latin1 =~ /$utf8/i bug. -- That he said that that that that is is is debatable, is debatable.
