Re: Re: RFC: mark functions as const for possibleoptimizations

From: Date: Mon, 17 Sep 2007 11:10:20 +0000
Subject: Re: Re: RFC: mark functions as const for possibleoptimizations
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-32357@lists.php.net to get a copy of this message
On Sun, 2007-09-16 at 20:02 +0100, Nuno Lopes wrote:
My proposal is the following: some functions when fed with constant arguments always return a constant value, too. e.g.: strlen('abcd') === 4.
I like the general idea. Would there be some caveats with stuff like this if it is possible to change the charset at runtime? I guess it is important to be aware of whether a function is affected by different settings (and if these settings can be changed at runtime) to conclude if a function really is deterministic at this level.
uhm, damn, right. strlen() wasn't a good example.. my bad, sorry :S Anyway, you got the idea :)
Nothing wrong with strlen as far as I can tell: - In PHP 5 we only have binary strings so strlen() works independent from any charsets and encodings by just counting bytes. - In PHP 6 we know - assuming the parameter is a constant string - the encoding at compile time, therefore it could be used. The only edge-case I see is if somebody uses mbstring.func_overload and overwrites strlen()
exactly. I was thinking in mbstring, too. As long as there is some run-time setting that can affect a function, we cannot replace its call blindly with its value. Then only a more intelligent optimizer can do inference on the code and figure out if it's safe or not to replace the function call. My proposal was to mark functions susceptible of that "blind" replacement only. Nuno

« previous php.internals (#32357) next »