Inline regexps and caching
brendan at mozilla.com
Sat Jan 24 18:48:03 PST 2009
On Jan 24, 2009, at 5:42 PM, Richard Cornford wrote:
> Ugly, and an example of using a hammer to crack a nut.
I do this all the time, works great ;-).
Seriously, there's more afoot than can be patched by resetting
> The issue is provoked by the fact that for a regular expression with
> the global flag set the - exec - method employs the regular
> expression object's - lastIndex - property, leaving it set to the
> end index of the last match made. Knowing that suggests that a
> simple 'solution' would be to explicitly set the regular expression
> object's - lastIndex - property to zero before using it. That must
> be cheaper than creating a new regular expression object just for
> the side effect of then having one with a zero - lastIndex - property.
The more general problem is shared mutable literal-expressed
singletons. In no other case (object or array initialiser, function
expressions, primitive literals) does evaluation return the singleton
created as if at parse time. Mutation hurts, sharing should be
explicit. To match the other kinds of literals and avoid bugs such as
Efficiency concerns are secondary but can be addressed by lightweight
cloning of a shared-immutable compiler-created regexp.
> In addition, knowing the mechanism also directs attention towards
> the global flag; does the regular expression being used need to have
> the global flag set in the first place? If the flag is not set then
> subsequent - exec - uses will always start at the zero index. The
> example regular expression used above only appears to be interested
> in making a single match so probably there was never a need to have
> the flag set.
This is an optimization challenge for implementors, not a reason to
specify a shared singleton with mutable state (lastIndex is mutable
and set to 0 even without the 'g' flag).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es-discuss